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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document specifies procedures used between the Serving GPRS Support Node (SGSN) and the Visitors 
Location Register (VLR) for co-ordination between GSM circuit switched services and GSM packet data services 
within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document specifies or references the procedures to provide co-ordination between the GSM circuit 
switched services controlled at the Visitors Location Register (VLR) and the GSM packet switched services controlled 
at the Serving GPRS Support Node (SGSN). The procedures specified in the present document are intended to optimise 
the use of the resources when an MS supports both GSM circuit switched services and GSM packet switched services. 
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Scope 



The present document specifies or references procedures used on the Serving GPRS Support Node (SGSN) to Visitors 
Location Register (VLR) interface for interoperability between GSM circuit switched services and GSM packet data 
services. 

The present document specifies the layer 3 messages and procedures on the Gs interface to allow coordination between 
databases and to relay certain messages related to GSM circuit switched services over the GPRS subsystem. 

The functional split between VLR and SGSN is defined in 3GPP TS 23.060. The required procedures between VLR and 
SGSN are defined in detail in the present document. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[I] [Void] 

[la] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] [Void] 

[3] [Void] 

[4] 3GPP TS 22.060: "General Packet Radio Service (GPRS); Service description; Stage 1". 

[5] 3GPP TS 23.003: "Numbering, addressing and identification". 

[6] 3GPP TS 23.007: "Restoration procedures". 

[6a] 3GPP TS 23.018: "Basic Call Handling; Technical realization". 

[7] 3GPP TS 23.122: "Non-Access-Stratum functions related to Mobile Station (MS) in idle mode". 

[8] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[9] 3GPP TS 43.064: "Overall description of the GPRS radio interface; Stage 2". 

[10] 3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects". 

[II] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[11a] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol". 

[12] 3GPP TS 44.064: "Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link 

Control (LLC) layer specification". 

[13] 3GPP TS 44.065: "Mobile Station (MS) - Serving GPRS Support Node (SGSN); Subnetwork 

Dependent Convergence Protocol (SNDCP)". 
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[14] 3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC-BSS) interface; 

Layer 3 specification". 

[15] 3GPP TS 48.018: "Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS 

Protocol (BSSGP)". 

[16] 3GPP TS 48.060: "Inband control of remote transcoders and rate adaptors for Enhanced Full Rate 

(EFR) and full rate traffic channels." 

[17] 3GPP TS 29.002: "Mobile Apphcation Part (MAP) specification". 

[18] 3GPP TS 49.008: "Apphcation of the Base Station System Application Part (BSSAP) on the E- 

interface". 

[19] 3GPP TS 29.010: "Information Element Mapping between Mobile Station - Base Station System 

(MS-BSS) and Base Station System - Mobile-services Switching Centre (BSS-MCS) Signalling 
Procedures and the Mobile Application Part (MAP)". 

[20] 3GPP TS 29.016: "General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - 

Visitors Location Register (VLR); Gs interface network service specification". 

[21] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[22] 3GPP TS 25.413: "UTRAN lu interface RANAP signalling". 

[23] 3GPP TS 23.195: "Provision of UE Specific Behaviour Information to Network Entities". 

[23 A] 3GPP TS 22.101: "Service Principles". 

[24] 3GPP TS 23.251: "Network sharing; Architecture and functional description". 

[25] 3GPP TS 32.422: "Subscriber and equipment trace; Trace control and Configuration Management 

(CM)". 

[26] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple 

Core Network (CN) nodes". 

[27] 3GPP TS 29.1 18: "MobiHty Management Entity (MME) - Visitor Location Register (VLR) SGs 

interface specification". 

2.2 Informative references 

[22A] 3GPP TS 41.061: "GPRS ciphering algorithm requirements". 

[23B] 3GPP TS 22.001: "Principles of circuit telecommunication services supported by a Public Land 

Mobile Network (PLMN)". 

[24] 3GPP TS 22.002: "Circuit Bearer Services (BS) supported by a Public Land Mobile Network 

(PLMN)". 

[25] 3GPP TS 22.003: "Circuit Teleservices supported by a Public Land Mobile Network (PLMN)". 

[26] [Void] 

[27] 3GPP TS 42.009: "Security aspects". 

[28] 3GPP TS 22.01 1: "Service accessibility". 

[29] 3GPP TS 22.016: "International Mobile station Equipment Identities (IMEl)". 

[30] 3GPP TS 42.017: "Subscriber Identity Modules (SIM); Functional characteristics". 

[31] 3GPP TS 22.030: "Man-Machine Interface (MMI) of the User Equipment (UE)". 

[32] [Void] 
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[33] [Void] 

[34] 3GPP TS 44.001: "Mobile Station - Base Station System (MS-BSS) interface; General aspects and 

principles". 

[35] 3GPP TS 24.002: "GSM - UMTS Public Land Mobile Network (PLMN) access reference 

configuration". 

[36] 3GPP TS 44.003: "Mobile Station - Base Station System (MS - BSS) interface; Channel structures 

and access capabilities". 

[37] 3GPP TS 44.004: "Layer 1 General requirements". 

[38] 3GPP TS 44.005: "Data Link (DL) layer General aspects". 

[39] 3GPP TS 44.006: "Mobile Station - Base Station System (MS - BSS) interface Data Link (DL) 

layer specification". 

[40] 3GPP TS 24.01 1 : "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio 

interface". 

[41] 3GPP TS 24.022: "Radio Link Protocol (RLP) for data and telematic services on the Mobile 

Station - Base Station System (MS-BSS) interface and the Base Station System - Mobile-services 
Switching Centre (BSS-MSC) interface". 

[42] 3GPP TS 27.060: "Mobile Station (MS) supporting Packet Switched Services". 

[43] 3GPP TS 48.006: "Signalling transport mechanism specification for the Base Station System - 

Mobile-services Switching Centre (BSS-MSC) interface". 

[44] 3GPP TS 48.014: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving 

GPRS Support Node (SGSN) interface; Gb interface layer 1". 

[45] 3GPP TS 48.016: "General Packet Radio Service (GPRS); Base Station System (BSS); Serving 

GPRS Support Node (SGSN) interface; Network Service". 

[46] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) 

across the Gn and Gp Interface". 

[47] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 

Packet Based services and Packet Data Networks (PDN)". 

[48] [Void] 

[49] [Void] 

[50] [Void] 

[51] [Void] 

[52] [Void] 

[53] [Void] 

[54] [Void] 

[55] [Void] 

[56] ITU-T Recommendations 1. 130: "Method for the characterization of telecommunication services 

supported by an ISDN and network capabilities of an ISDN". 

[57] ITU-T Recommendation Q.65: "The unified functional methodology for the characterization of 

services and network capabilities". 

[58] ITU-T Recommendation Q.702: "Signalling data link". 

[59] ITU-T Recommendation Q.703 : "Signalling link" . 
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[60] ITU-T Recommendation Q.704: "Signalling network functions and messages". 

[61] ITU-T Recommendation Q.71 1 (03/93): "Functional description of the signalling connection 

control part". 

[62] ITU-T Recommendation Q.712 (03/93): "Definition and function of signalling connection control 

part messages". 

[63] ITU-T Recommendation Q.713 (03/93): "Signalling connection control part formats and codes". 

[64] ITU-T Recommendation Q.714 (03/93): "Signalling connection control part procedures". 

[65] ANSI Tl.l 1 1 (1996): "Signalling System No. 7 (SS7); Message Transfer Part". 

[66] ANSI Tl.l 12 (1996): "Signalling System No. 7 (SS7); Signalling Connection Control Part 

Functional Description". 



3 Definitions, symbols and abbreviations 

For the purposes of the present document the definitions, symbols and abbreviations given in 3GPP TR 21.905 and in 
3GPP TS 23.060 apply. 



4 Description of the association between a VLR and an 

SGSN 

The Gs interface connects the databases in the MSC/VLR and the SGSN. The procedures described in the present 
document are used to co-ordinate the location information of MSs that are IMSI attached to both GPRS and non-GPRS 
services. The Gs interface is also used to convey some circuit switched related procedures via the SGSN. 

The basis for the interworking between a VLR and an SGSN is the existence of an association between those entities 
per MS. An association consists of the SGSN storing the number of the VLR serving the MS for circuit switched 
services and the VLR storing the number of the SGSN serving the MS for packet switched services. The association is 
only applicable to MSs in class-A mode of operation and MSs in class-B mode of operation. 

All the messages described in the present document use the SCCP class connectionless service. 

When the return option in SCCP is used and the sender receives an N_NOTICE indication from SCCP, the sending 
entity shall report to the Operation and Maintenance system (see ITU-T Recommendation Q.714). 

The behaviour of the VLR and the SGSN entities related to the Gs interface are defined by the state of the association 
for an MS. Individual states per association, i.e. per MS in class-A mode of operation and MS in class-B mode of 
operation, are held at both the VLR and the SGSN. 

4.1 Association at the VLR 

The states associated to the Gs interface in the VLR are specified in this clause. The state diagram at the VLR is shown 
in figure 4.1. The state diagram does not include the message error handling specified in clause 16. 
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4.1.1 States at the VLR 

Gs-NULL 

There is no association with an SGSN for the MS and therefore the VLR considers that the MS is IMSI detached 
for GPRS services. In this state no BSSAP+-MS-INFORMATION-REQUEST or BSSAP+-MM- 
INFORMATION-REQUEST messages are sent to the SGSN. The VLR may initiate paging on the Gs interface 
if the 'Confirmed by Radio Contact' restoration indicator in the VLR is set to 'false' (see 3GPP TS 23.007). Any 
message from the SGSN is ignored apart from the BSSAP+-LOCATION-UPDATE-REQUEST message, the 
BSSAP+-GPRS-DETACH-INDICATION message and the BSSAP+-IMSI-DETACH-INDICATION message. 

LA-UPDATE PRESENT 

The VLR has received a BSSAP+-LOCATION-UPDATE-REQUEST message from the SGSN. In this state the 
VLR may be waiting for the outcome of the Update Location procedure from the HLR. The VLR shall send 
BSSAP+-PAGING-REQUEST messages to MSs in class-A and MSs in class-B mode of operation via only the 
Gs interface. 

Gs-ASSOCIATED 

The VLR considers that the MS is attached to both GPRS and non-GPRS services. In this state the VLR sends 
BSSAP-H-PAGING-REQUEST messages to MSs in class-A mode of operation and and MSs in class-B mode of 
operation via only the Gs interface. The VLR can perform the MS Identification procedure and the MM 
information procedure. 
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NOTE: Receipt of a BSSAP+-RESET-INDICATION message from the SGSN may change or not the state of the 
Gs interface of all the associations associated to the restarted SGSN, see subclause 12.3. 

Figure 4.1/3GPP TS 29.018: State diagram at the VLR 

4.2 Association at the SGSN 

The states and MM context variables associated to the Gs interface in the SGSN are specified in this clause. The state 
diagram at the SGSN is shown in figure 4.2. The state diagram does not include the message error handling specified in 
clause 16. 
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4.2.1 MM context variables at the SGSN 

VLR-Reliable: Boolean 

Set to 'false' when the SGSN has received a reset indication from the VLR. The SGSN may request to the MS, 
upon reception of the next routeing area update (either periodic routeing area update or combined routeing and 
location area update) procedure, to re-attach to non-GPRS services if the MS is still IMSI attached to non-GPRS 
services. Alternatively the SGSN may upon reception of a combined routeing and location area update request or 
a periodic routeing area update from a MS that is still attached for non-GPRS service, perform immediately the 
location update for non-GPRS services procedure. 



SGSN-Reset: 



Boolean 



Set to 'true' when the SGSN restarts after a failure. The 'SGSN-Reset' variable is unique within an SGSN and it 
applies to all the MM context stored in the SGSN. 

4.2.2 States at the SGSN 

Gs-NULL 

There is no association with a VLR for the MS and therefore the SGSN considers that the MS is IMSI detached 
of non-GPRS services. In this state the SGSN accepts BSSAP-n-P AGING-REQUEST messages to MSs only if 
the 'SGSN-Reset' restoration indicator in the SGSN is set to 'true'. 

LA-UPDATE Requested 

The SGSN has sent a BSSAP-n-LOCATION-UPDATE-REQUEST message to the VLR. In this state the SGSN 
waits for the outcome of the Location Update for non-GPRS procedure at the VLR before sending the response 
to the MS. In this state the SGSN accepts BSSAP-n-P AGING-REQUEST messages. 

Gs-ASSOCIATED 

The SGSN stores an association for that MS. In this state the SGSN performs the Location Update for non-GPRS 
services procedure towards the VLR for MSs in class-A and MSs in class-B mode of operation, e.g. when the 
MS moves to a new LA. All conditions describing when to trigger the location update for non-GPRS services 
procedure are listed in subclause 6.2.1. 
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Figure 4.2/3GPP TS 29.018: State diagram at the SGSN 
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5 Paging for non-GPRS services procedure 

5.1 General description 

This procedure is used by the VLR to send a BSSAP+-P AGING-REQUEST message to an MS via the GPRS service. 
This procedure appHes to MSs that are simuhaneously IMSI attached for GPRS services and non-GPRS services. The 
procedure can be performed simultaneously with any other procedure at the Gs interface. 

5.2 Procedures in the VLR 

The VLR shall handle the timers, queuing and retransmission for sending the BSSAP-n-P AGING-REQUEST message 
on the Gs interface in the same way that it handles the sending of a PAGING message on the A or lu-CS interface. 

5.2.1 Paging Initiation 

When a VLR has to page a GPRS MS it shall check whether the MSC has an SCCP connection for that MS. If no SCCP 
connection exists the VLR checks the state of the association to an SGSN and the value of the restoration indicators for 
that MS. The VLR sends BSSAP-n-P AGING-REQUEST messages to the SGSN if the state of the association for the 
MS is Gs-ASSOCIATED, LA-UPDATE-PRESENT or if the state of the association is Gs-NULL and the 'Confirmed 
by Radio Contact' restoration indicator is set to 'false'. The sending of the BSSAP-n-P AGING-REQUEST message does 
not change the state of the association with the SGSN. 

If the 'Confirmed by Radio Contact' restoration indicator is set to 'true', the VLR shall include the Location area 
identifier IE into the BSSAP-n-P AGING-REQUEST message, otherwise (i.e. after a VLR failure) the Location area 
identifier IE shall not be included. When sending the BSSAP-n-P AGING-REQUEST message, the VLR shall start timer 
T5. 

If the state of the association is Gs-NULL and the restoration indicator 'Confirmed by Radio Contact' is set to 'false', the 
VLR shall also perform a search procedure as specified in 3GPP TS 23.018. 

While domain specific access control of the PS domain is ongoing the VLR shall be configured to send paging 
messages on the Gs, A and lu-CS interfaces. The VLR may apply implementation specific rules for sending the paging 
on the A and lu-CS interfaces; e.g. paging on the A and lu-CS interfaces may be limited to cases when the GPRS MS 
did not respond to a first paging on Gs interface. 



5.2.2 Paging Response 



The VLR stops the paging procedure on expiry of timer T5 or on receipt of an SCCP connection establishment 
containing the Initial L3 message from the MS via the A or lu-CS interface. 

If the paging response is received from a location area which differs from the one stored in the VLR, the VLR shall 
move the Gs association to the Gs-NULL state after the MS has been authenticated successfully. 



5.2.3 Paging Failure 



On receipt of a BSS AP-n-PAGING-REJECT message before the timer T5 expires, the VLR stops timer T5, the 
association is moved to the Gs-NULL state and within this state the association is marked with the contents of the Gs 
Cause IE. 

5.2.4 MS unreachable 

On receipt of a BSSAP-n-MS-UNREACHABLE message before the timer T5 expires, the VLR stops timer T5 and the 
paging procedure for that paging request towards the SGSN is stopped. The state of the association at the VLR is not 
changed. 
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5.3 Procedures in the SGSN 

The SGSN accepts BSSAP+-P AGING-REQUEST messages in any state of the association apart from Gs-NULL. 
Nevertheless the SGSN also accepts BSSAP+-P AGING-REQUEST messages in the Gs-NULL state if the 'SGSN- 
Reset' restoration indicator at the SGSN is set to 'true'. When an SGSN receives a BSSAP-n-P AGING-REQUEST 
message from a VLR, the SGSN shall first check if the MS is known by the SGSN. The handling of the paging request 
depends on the state of the association and the MM context variables at the SGSN: 

a) The MS is known and the restoration indicator 'SGSN-Reset' at the SGSN is set to 'false': 

If the MS is considered to be IMSI attached for GPRS and non-GPRS services (i.e. the association is not in 
the state Gs-NULL), the SGSN shall page the MS based on the location information stored in the SGSN. If 
the location area stored in the SGSN differs from the one received in the BSSAP-n-P AGING-REQUEST 
message, the SGSN shall use the IMSI to page the MS. If the BSSAP-n-P AGING-REQUEST message does 
not include the Location area identifier information element, the SGSN may set the "VLR-Reliable" MM 
context variable to "false". 

If the MS is marked as IMSI detached for GPRS services or IMSI (implicitly or explicitly) detached for non- 
GPRS services (i.e. the state of the association is Gs-NULL), the SGSN shall return a BSSAP-n-P AGING- 
REJECT message to that VLR indicating in the Gs Cause IE the detach circumstance ('IMSI detached for 
GPRS services', 'IMSI detached for non-GPRS services' or 'IMSI implicitly detached for non-GPRS 

services'). 

- If the MS is marked as unreachable (i.e. the PPF flag is set to 'false') the SGSN shall return a BSSAP-n-MS- 
UNREACHABLE message to that VLR indicating in the Gs Cause IE 'MS unreachable'. The state of the 
association does not change at the SGSN. 

b) The MS is known and the restoration indicator 'SGSN-Reset' at the SGSN is set to 'true': 

- If the BSSAP-H-PAGING-REQUEST message includes the Location area identifier IE, the SGSN shall page 
the MS in all the routeing areas served by the SGSN that are included in the location area indicated in the 
Location area identifier IE. 

- If the BSS AP-H-PAGING-REQUEST message does not include the Location area identifier IE, the SGSN 
may page in all the routeing areas served by the SGSN that are also served by the sending VLR. 

NOTE 1 : The SGSN can handle the paging request as a) for the purpose of optimization if the MS is known. 

c) The MS is not known and the restoration indicator 'SGSN-Reset' at the SGSN is set to 'false': 

- The SGSN shall return a BSSAP-n-PAGING-REJECT message to that VLR indicating in the Gs Cause IE 
'IMSI unknown'. 

d) The MS is not known and the restoration indicator 'SGSN-Reset' at the SGSN is set to 'true': 

If the VLR provides the Location area identifier IE, the SGSN shall page within the location area indicated 
by the VLR. Otherwise the SGSN may page in all the routeing areas served by the SGSN that are also served 
by the sending VLR. 

If the SGSN accepts the paging request, the SGSN shall process the BSSAP-n-PAGING-REQUEST message before 
sending the message on the Gb interface. The result of the processing on the BSSAP-n-P AGING-REQUEST message is 
the PAGING CS message (see 3GPP TS 48.018) sent on the Gb interface. 

The SGSN shall not retransmit the PAGING CS message. 

If within a location area there are cells that do not support GPRS services, the SGSN shall group these cells under a 
'null RA'. The SGSN will perform the paging procedure described above within both the RA(s) derived from the 
location information and the 'null RA(s)' of the corresponding location area(s) (see 3GPP TS 24.008). 

NOTE 2: The eMLPP priority information element relates to relative priorities within the paged MS and not to the 
priority in the sending of PAGING CS messages by the BSS. 
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6 Location Update for non-GPRS services procedure 

6.1 General description 

The location update for non-GPRS services procedure is a general procedure used by MSs in class-A mode of operation 
and MSs in class-B mode of operation. This procedure allows MSs and network to perform: 

- Combined IMSI attach for GPRS and non-GPRS services; 

- IMSI attach for non-GPRS services if the MS is already IMSI attached for GPRS services; 

- IMSI attach for GPRS services indication to the VLR if the MS is already IMSI attached for non-GPRS services; 

- Normal Location Update procedure to the VLR if the MS is IMSI attached for both GPRS and non-GPRS 

services; 

- Reallocation of TMSI to an MS . 

The Location Update for non-GPRS services procedures in the Gs interface is always started as a consequence of a 
direct action by the MS. The combined routeing area update procedure is further specified in 3GPP TS 23.060 and 
3GPPTS 24.008. 

The Location Update for non-GPRS services procedure is used by the SGSN to forward to the VLR those parts of the 
combined routeing area update or IMSI attach procedure which belong to the non-GPRS services. This means that non- 
GPRS related requests which are included in the combined request, are sent from the SGSN to the VLR. The procedure 
is also used by the SGSN to indicate to the VLR when an IMSI attach to GPRS services has been performed by an MS 
that was already IMSI attached to non-GPRS services. The SGSN may also forward a BSSAP-n-TMSI- 
REALLOCATION-COMPLETE message from the MS to the VLR. 

The VLR shall acknowledge the BSSAP-n-LOCATION-UPDATE-REQUEST message. When the VLR processes the 
request it does not perform authentication because it relies on the SGSN's security functions. 

When an MS is IMSI attached for GPRS and non-GPRS services, any implicit detach timer in the VLR shall be 
stopped. Instead the Paging Proceed Flag in the SGSN is used to determine the likely availability of the MS to the 
network. Upon reception of the periodic Routeing Area Update message the SGSN does not report to the VLR , and the 
state of the association at the SGSN is not changed. When the MS performs a detach only from the GPRS system, and 
the VLR's implicit detach timer is not already running, the GPRS detach indication to the VLR shall cause the VLR's 
implicit detach timer to be restarted from its initial value. 

If the SGSN performs an implicit detach for both GPRS and non-GPRS traffic, then the SGSN shall indicate to the VLR 
a BSSAP-H-IMSI-DETACH-INDICATION message with cause ImpHcit SGSN initiated IMSI detach from GPRS and 
non-GPRS service', as further described in clause 'Implicit IMSI detach from non-GPRS service procedure' (the implicit 
IMSI detach message indicates that the MS is unavailable for both GPRS and non-GPRS services). 

The IMSI attach for GPRS services to the VLR, when the MS is already IMSI attached for non-GPRS services, is 
requested by the MS sending a combined IMSI attach for GPRS and non-GPRS services message to the SGSN, as 
further specified in 3GPP TS 23.060 and 3GPP TS 24.008. 

6.2 Procedures in the SGSN 

The Location Update for non-GPRS services is initiated with a combined routeing area update procedure or a 
IMSI/GPRS attach procedure. On receipt of a Routeing Area Update message, the SGSN shall handle the GPRS related 
request as specified in 3GPP TS 24.008. The Location Update for non-GPRS services procedure may be handled by the 
SGSN in parallel to the Update Location procedure to the HLR. The SGSN shall wait for the outcome of both location 
update procedures towards the VLR and the HLR before sending the response message to the MS (see 
3GPP TS 24.008). 
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6.2.1 Location Update Initiation 



If timer T6-1 is not running, the SGSN shall start the Location Update for non-GPRS service procedure when it receives 
from the MS: 

an Attach request indicating combined IMSI and GPRS attach; 

- an Attach request indicating GPRS attach while IMSI attached; 

a Combined Routeing and Location Area Update request indicating IMSI attach; 

a Combined Routeing and Location Area Update request indicating that the Location Area has changed; 

a Combined Routeing and Location Area Update request if the MS Network Capability IE indicates that EMM 
Combined procedures are supported by the MS; 

a Combined Routeing and Location Area Update request, if the state of the association is Gs-NULL; or 

a Combined Routeing and Location Area Update request when the SGSN serving the MS has changed. 

If timer T6-1 is not running, the SGSN may start the Location Update for non-GPRS service procedure when it receives 
from the MS: 

- a Combined Routeing and Location Area Update request or a periodic Routeing Area Update, if the 'VLR- 
Reliable' MM context variable for the MS is set to 'false' (see section 11.3). 

For networks not supporting the feature "Intra Domain Connection of RAN Nodes to Multiple CN Nodes" the number 
of the VLR is derived from the RAI where the MS is camping. For networks supporting the feature "Intra Domain 
Connection of RAN Nodes to Multiple CN Nodes", the VLR number is derived as described in 3GPP TS 23.236 [26]. 
The SGSN starts Timer T6-1. The BSSAP-n-LOCATION-UPDATE-REQUEST message includes the Old location area 
identifier. If the SGSN received the Old location area identification from the MS and the network supports S 1 mode, the 
SGSN includes the Old location area identification received from the MS as the Old location area identifier. If the 
SGSN did not receive the Old location area identification from the MS or if the network does not support S 1 mode, the 
SGSN derives the Old location area identifier from the Old routing area identification received in the ROUTING AREA 
UPDATING REQUEST message (see 3GPP TS 24.008 [11]). The SGSN shall also include the new Location Area 
Identifier where the MS is currently camping. The new LAI is derived from the RAI. 

In networks supporting the feature "Intra Domain Connection of RAN Nodes to Multiple CN Nodes", the SGSN shall 
support load re-distribution of MSs to another VLR than the current one as follows: 

When the SGSN receives a periodic Routeing Area Update request or a Combined Routeing and Location Area 
Update request, the SGSN shall check whether for this MS there is an association to a VLR for which load re- 
distribution has been initiated in the SGSN by O&M. If yes, the SGSN derives the new VLR number as 
described in 3GPP TS 23.236 [26]. The SGSN shall then send the BSSAP-n-LOCATION-UPDATE-REQUEST 
message to the new selected VLR. 

The BSSAP-H-LOCATION-UPDATE-REQUEST message includes the type of location update performed by the MS in 
the GPRS location update type IE. If the MS has performed a combined attach request or a combined routing and 
location area update request with IMSI attach, the SGSN indicates 'IMSI attach', otherwise the SGSN indicates 'Normal 
location update'. 

The BSSAPh-LOCATION-UPDATE-REQUEST message shall include the TMSI status if received from the MS. 

If the SGSN supports the "Provision of UE Specific Behaviour Information to Network Entities" (see 3GPP TS 23.195 
[23]), or the 'Automatic Device Detection' (see 3GPP TS 22.101 [23 A]) or the 'Trace for Management Based 
Activation/Deactivation' (see 3GPP TS 32.422 [25]),, the BSSAPh-LOCATION-UPDATE-REQUEST message shall 
include the IMEISV. 

If timer T6-1 is running: 

If the SGSN receives from the MS: 
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an Attach request indicating combined IMSI and GPRS attach; 
- an Attach request indicating GPRS attach while IMSI attached; or 

a Combined Routeing and Location Area Update request with or without IMSI attach. 

Then: 

if the new LAI is the same as in the outstanding request, the SGSN shall not process this new request and shall 
wait for the VLR's response to the ongoing procedure; or 

if the new LAI is different but is in the same VLR as the outstanding request: 

any response from the VLR to the oustanding request is ignored; 

Timer T6-1 shall be stopped and reset; and 

The SGSN shall start the Location Update for non-GPRS service procedure; or 
if the new LAI is different, and is in a different VLR to the outstanding request: 

any response from the previously addressed VLR to the oustanding request is ignored; 

Timer T6-1 shall be stopped and reset; and 

the SGSN shall start the Location Update for non-GPRS service procedure. 

When the SGSN receives from the MS a Routeing Area Update request and the SGSN serving the MS has changed, the 
SGSN shall stop and reset timer T6-1. 

6.2.2 Location Update Response 

If the SGSN receives a BSSAP-n-LOCATION-UPDATE-ACCEPT message from the VLR, the SGSN shall: 

stop timer T6-1; and 

move the state of the association to Gs-ASSOCIATED; 

set the the MM context variable 'VLR-Reliable' to 'true'; and 

indicate to the MS the acceptance of the VLR to the Location Update procedure. The message to the MS 
includes the Routeing Area Identity, from which the MS is able to extract the location area identity for which the 
location update procedure succeeded (see 3GPP TS 24.008). 

The SGSN shall wait for the outcome of the Location Update for non-GPRS service procedure towards the VLR before 
sending a response to location update procedure to the MS. Any Reject cause that needs to be reported to the MS is 
specified in 3GPP TS 24.008. 

If the VLR included the Mobile Identity IE in the BSSAP-n-LOCATION-UPDATE-ACCEPT message, the SGSN shall 
forward the information received to the MS. If the Mobile Identity IE contains a new TMSI it will cause the MS to 
perform a TMSI reallocation procedure, while an IMSI causes the MS to deallocate its TMSI. In case a new TMSI was 
allocated for the MS the SGSN shall send to the VLR the BSSAP-n-TMSI-REALLOCATION-COMPLETE message 
when the SGSN receives Attach Complete or the the Routeing Area Complete message from the MS. 
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6.2.3 Location Update Failure 

If the SGSN receives a BSSAP+-LOCATION-UPDATE-REJECT message from the VLR, the SGSN shall: 

stop timer T6-1; 

move the state of the association to Gs-NULL; and 

indicate to the MS the rejection of the VLR of the Location Update procedure as specified in 3GPP TS 24.008. 
The Reject cause value sent by the VLR shall be forwarded to the MS. 

6.2.4 Abnormal cases 

If timer T6-1 expires, the SGSN shall abort the Location Update for non-GPRS service procedure and indicate this to 
the MS with the Reject cause value 'MSC temporarily not reachable'. The state of the association to the VLR shall be 
Gs-NULL. 

If the SGSN receives a BSSAPh-LOCATION-UPD ATE- ACCEPT message and timer T6-1 is not running then: 

if timer T8 is running (see clause 8), the message shall be ignored; 

if timer T9 is running (see clause 9), the message shall be ignored; or 

if timers T8 and T9 are not running: 

if the state of the association to the VLR is GS-ASSOCIATED, the message shall be ignored; or 

if the state of the association to the VLR is different than GS-ASSOCIATED, the message shall be treated as 
a message incompatible with the protocol state of the SGSN (see clause 16.3). 

6.3 Procedures in the VLR 

When a VLR receives a BSSAP-n-LOCATION-UPDATE-REQUEST message it shall check whether the IMSI is 
known. If the IMSI is not known the VLR shall retrieve the MM context of the MS from the HLR. 

For a VLR supporting the "Provision of UE Specific Behaviour Information to Network Entities" (see 3GPP TS 23.195 
[23]) the following applies: 

- The VLR shall store the IMEISV value received in the BSSAPh-LOCATION-UPD ATE-REQUEST message in 
the MM context for that MS. 

- If the VLR receives a BSSAPh-LOCATION-UPD ATE-REQUEST message without IMEISV information 
element, the MSC/VLR shall request the IMEISV from the MS at the next lu-CS or A interface connection 
establishment. 

6.3.1 Location Update Response 

If the Location Update is accepted by the VLR and, if necessary by the HLR, the VLR shall: 
move the association to the Gs-ASSOCIATED state; 
set the restoration indicator 'Confirmed by Radio Contact' to 'true'; 

- update the association by storing the SGSN number included in the BSSAPh-LOCATION-UPDATE-REQUEST 

message; and 

- send a BSSAPh-LOCATION-UPDATE-ACCEPT message to the sending SGSN. This message includes the 
Location Area Identification received in the new Cell Global Identity IE in the previous BSSAPh-LOCATION- 
UPDATE-REQUEST message. 

6.3.2 Location Update Failure 

If the Location Update is rejected by the VLR it shall: 
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- Send a BSSAP+-LOCATION-UPDATE-REJECT message to the SGSN with the appropriate reject cause as 
indicated in 3GPP TS 24.008 and indicate to the SGSN the Location area identifier received in the corresponding 
BSSAP+-LOCATION-UPDATE-REQUEST message; and 

Move the association from any state to Gs-NULL. 

6.3.3 TMSI reallocation procedure 

If the VLR decides to reallocate the TMSI to the MS it shall include the new TMSI in the BSSAP+-LOCATION- 
UPD ATE- ACCEPT message. If the VLR decides to deallocate the TMSI of the MS it shall include the IMSI of the MS 
in the BSSAP+-LOCATION-UPDATE-ACCEPT message. After sending the BSSAP+-LOCATION-UPDATE- 
ACCEPT message with a new TMSI the VLR starts timer T6-2. 

NOTE: In the BSSAP+-LOCATION-UPDATE-REQUEST the SGSN may indicate, that there is no valid TMSI 
available in the MS. This information may be used by the VLR to decide whether to reallocate a new 
TMSI to the MS. 

Upon receipt of the BSSAP+-TMSI-REALLOCATION-COMPLETE message, the VLR stops the timer T6-2 and 
considers the new TMSI as valid. 

If an IMSI was sent to the MS, the VLR considers the old TMSI as deleted. 

If no BSSAP+-TMSI-REALLOCATION-COMPLETE message is received by the VLR before the timer T6-2 expires, 
the VLR aborts the TMSI reallocation procedure. The VLR may still perform the TMSI reallocation procedure via the 
A or lu-CS interface. The outcome of the TMSI reallocation procedure does not change the state of the association. The 
VLR uses the IMSI or the new TMSI or, if available, the old TMSI for paging. 

6.3.4 Abnormal cases 

The following abnormal cases can be identified: 

i) MM signalling via the A or lu-CS interface 

If the VLR receives a Location Update request or an IMSI detach indication from the MS by the A or lu-CS 
interface when the state of the association in the VLR is not Gs-NULL, the VLR shall move the state of the 
association to Gs-NULL. 

ii) Additional Location Update Request 

If the state of the association in the VLR is in the LA-UPDATE PRESENT state and a BSSAPh-LGCATIGN- 
UPDATE-REQUEST message is received, then: 

If the message is from the same SGSN and indicates the same New Location Area as the outstanding location 
update request, then this additional BSSAPh-LOCATION-UPDATE-REQUEST message shall be ignored; 

If the message is from the same SGSN but indicates a different New Location Area to the outstanding 
location update request, then this additional BSSAPh-LOCATION-UPDATE-REQUEST message shall be 
treated and the VLR shall not send any response to the previous BSSAPh-LOCATION-UPDATE- 
REQUEST message; or 

If the message is from a different SGSN (indicating either the same or different New Location Area) to the 
outstanding location update request, then this additional BSSAPh-LOCATION-UPDATE-REQUEST 
message shall be treated and the VLR shall not send any response to the previous BSSAPh-LOCATION- 
UPDATE-REQUEST message. 

iii) Detach signalling from SGSN 

If the state of the association in the VLR is in the LA-UPDATE PRESENT state and either a BSSAPh-GPRS- 
DETACH-INDICATION or a BSSAPh-IMSI-DETACH-INDICATION message is received, then, the Location 
Update for non-GPRS services procedure shall be abandoned in the VLR (neither a BSSAP+LOCATION- 
UPDATE-ACCEPT nor a BSSAP+LOCATION-UPDATE-REJECT messages is sent) and the further actions 
described in clauses 8 or 9 or 10 are followed. 

iv) Signalling via SGs interface 
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If the VLR receives for a UE a SGsAP-LOCATION -UPDATE-REQUEST message (as defined in 

3GPP TS 29.1 18 [27]) from an MME when the state of the association for this UE in the VLR is not Gs-NULL, 

the VLR shall move the state of the association to Gs-NULL. 

v) New Location Update Request during TMSI reallocation procedure 

If the VLR receives a BSSAP-n-LOCATION-UPDATE-REQUEST message while T6-2 is running, the VLR 
shall stop timer T6-2, abort the TMSI reallocation procedure and proceed with the new location update for non- 
GPRS services procedure. If the VLR needs to page the MS during the new location update for non-GPRS 
services procedure, the VLR uses the IMSI or the new TMSI from the aborted TMSI reallocation procedure or, if 
available, the old TMSI for paging. 



7 Non-GPRS alert procedure 

7.1 General description 

This procedure is used by the VLR to request from an SGSN an indication when activity (either signalling or data 
transmission) from an MS is detected. This procedure can be invoked at any time by the VLR. The BSSAP-n- ALERT- 
REQUEST message shall be acknowledged by the SGSN. 

7.2 Procedures in the VLR 

7.2.1 Alert Initiation 

The VLR may start the Non-GPRS alert procedure at any time. When the VLR wants to request to an SGSN that further 
activity from an MS shall reported by the SGSN, the VLR shall send an BSSAP-n-ALERT-REQUEST message to that 
SGSN. The VLR starts timer T7 when the BSSAP-n-ALERT-REQUEST message is sent. 

7.2.2 Alert Response 

When a BSSAP-n-ALERT-ACK message is received, the VLR shall stop the timer T7. The state of the association is not 
changed. 

7.2.3 Alert failure 

If a BSSAP-H- ALERT-REJECT message is received, the VLR shall stop the timer T7, move the state of the association 
to Gs-NULL and within this state the association is marked with the contents of the Gs Cause IE. 

7.2.4 Alert Indication 

The VLR shall not change the state of the association upon reception of an BSSAP-n-MS- ACTIVITY-INDICATION 

message. 

7.2.5 Abnormal cases 

If no BSSAP-H- ALERT- ACK message is received before the timer T7 expires, the VLR shall retransmit the BSSAP-n- 
ALERT-REQUEST message a maximum of N7 times. If no BSSAP-n-ALERT-ACK message is received after that, a 
report shall be made to the O&M system. The state of the association is not changed. 
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7.3 Procedures in the SGSN 

7.3.1 Alert response 

The SGSN may receive a BSSAP+-ALERT-REQUEST message at any state of the association. Upon receipt of an 
BSS AP+-ALERT-REQUEST message from the VLR and if the IMSI is known in the SGSN, the SGSN shall reply with 
a BSS AP+- ALERT- ACK message and set the NGAF. 

7.3.2 Alert failure 

If a BSS AP+- ALERT-REQUEST message is received for an IMSI that is unknown at the SGSN, the SGSN shall return 
a BSS AP-H- ALERT-REJECT message to the VLR indicating the Gs Cause IE value IMSI unknown'. 

7.3.3 Alert indication 

The SGSN shall to report to the VLR upon detection of any activity (either signalling or data) from the MS if the NGAF 
is set. If the SGSN detects GPRS signalling that leads to a procedure towards the VLR, the SGSN shall follow this 
procedure and reset the NGAF. If the SGSN detects activity that does not lead to any procedure towards the VLR, the 
SGSN shall send an BSSAP-n-MS-ACTIVITY-INDICATION message towards the VLR and reset the NGAF. 

8 Explicit IIVISI detach from GPRS services procedure 

8.1 General description 

This procedure is used by the SGSN to indicate to the VLR that the MS has been IMSI detached from GPRS service 
and therefore the association between the SGSN and the VLR has to be deactivated. This procedure only applies to MSs 
that are not in the Gs-NULL state at the SGSN. The procedures specified in this clause apply to GPRS detach indication 
initiated by the MS or by the network as specified in 3GPP TS 23.060. 

The procedure is also used by the SGSN to indicate to the VLR when a combined Routing and Location Area Update 
procedure has been rejected by the SGSN. 

The procedure is also used by the SGSN to indicate to the VLR when a periodic Routing Area Update procedure has 
been rejected by the SGSN for an MS for which a Gs association exists. 

The Explicit IMSI detach from GPRS services procedure aborts any other ongoing procedure related to this MS on the 
Gs interface in the SGSN and in the VLR. 

The VLR and the MS should be synchronised as to whether the PBCCH or the BCCH is used, for any of the subsequent 
paging. In order to achieve this, the SGSN shall attempt to inform the VLR about the detach event by using a retry 
scheme if the initial delivery of the BSSAP-n-GPRS-DETACH-INDICATION message fails. 

8.2 Procedures in the SGSN 
8.2.1 Explicit GPRS detach initiation 

The SGSN shall send a BSSAP-n-GPRS-DETACH-INDICATION message to a VLR if: 

- The SGSN receives a GPRS only detach from the MS; 

The SGSN performs network-initiated GPRS detach procedure; 

The combined Routing and Location Area Update procedure is rejected at the SGSN; or 

The periodic Routing Area Update procedure is rejected at the SGSN for an MS for which a Gs association 
exists. 
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If the SGSN receives a Detach Request from an MS and the state of the association to a VLR for that MS is not Gs- 
NULL, the SGSN shall check the detach type indicated in the message. If the MS is indicating GPRS detach the SGSN 
shall send a BSSAP+-GPRS-DETACH-INDICATION message to the VLR indicating 'MS initiated IMSI detach from 
GPRS service'. 

If the SGSN decides to perform a network-initiated GPRS detach and the state of the association to a VLR for that MS 
is not Gs-NULL, the SGSN shall send a BSSAP+-GPRS-DETACH-INDICATION message to the VLR indicating 
'Network initiated IMSI detach from GPRS service'. 

If the combined Routing and Location Area Update procedure or periodic Routing Area Update procedure is rejected at 
the SGSN for an MS with an association state different from Gs-NULL, the SGSN shall send a BSSAP-n-GPRS- 
DETACH-INDICATION to the VLR indicating 'GPRS services not allowed'. The SGSN then sends, for example, a 
Routing Area Update Reject message as specified in 3GPP TS 24.008. 

After the sending of the BSSAP-n-GPRS-DETACH-INDICATION message, the SGSN shall move the state of the 
association to Gs-NULL. The SGSN shall start timer T8 upon transmission of the BSSAP-n-GPRS-DETACH- 
INDICATION message and if timer T6-1 is running, timer T6-1 shall be stopped and reset. 

8.2.2 Explicit GPRS detacin Response 

If the SGSN receives a BSSAP-n-GPRS -DETACH- ACK message from the VLR, the SGSN shall stop timer T8. The 
SGSN shall not wait for the reception of the BSSAP-n-GPRS-DETACH-ACK message before sending (if needed) the 
confirmation of the detach to the MS . 

8.2.3 Abnormal cases 

If no BSSAP-H-GPRS-DETACH-ACK message is received by the SGSN to a previous BSSAP-n-GPRS-DETACH- 
INDICATION message before timer T8 expires, the SGSN shall repeat the BSSAP-n-GPRS-DETACH-INDICATION 
message a maximum of N8 times. If no BSSAP-n-GPRS-DETACH-ACK message is received after that, a report shall 
be made to the O&M system. The state of the association during the acknowledgement procedure remains Gs-NULL. 

8.3 Procedures in the VLR 

When a VLR receives a BSSAP-n-GPRS-DETACH-INDICATION message, the VLR shall send a BSSAP-n-GPRS- 
DETACH-ACK message to the sending SGSN. The state of the association for the MS shall be moved from any state to 
Gs-NULL. The VLR marks the association as 'IMSI detached for GPRS services' with the reason indicated in the IMSI 
detach from GPRS service type IE. 

If the VLR's implicit detach timer is not running then, the VLR shall set and restart the implicit detach timer upon 
reception of a BSSAP-n-GPRS-DETACH-INDICATION message. If the VLR's implicit detach timer is running (ie the 
state of the association was already Gs-NULL) then, the reception of a BSSAP-n-GPRS-DETACH-INDICATION 
message shall not affect the VLR's implicit detach timer. 



Explicit IIVISI detach from non-GPRS services 
procedure 



9.1 General description 



This procedure is used by the SGSN to indicate to the VLR that the MS has performed IMSI detach from non-GPRS 
services and therefore the association between the SGSN and the VLR has to be deactivated. This procedure only 
applies to MSs that are not in the Gs-NULL state at the SGSN. The procedures specified in this clause only apply to 
IMSI detach or combined IMSI and GPRS detach requests. 

The explicit IMSI detach from non-GPRS services procedure aborts any other ongoing procedure related to this MS on 
the Gs interface in the SGSN and in the VLR. 
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The VLR and the MS should be synchronised as to whether the PBCCH or the BCCH is used, for any of the subsequent 
paging. In order to achieve this, the SGSN shall attempt to inform the VLR about the detach event by using a retry 
scheme if the initial delivery of the BSSAP+-IMSI-DETACH-INDICATION message fails. 

9.2 Procedures in the SGSN 

9.2.1 Explicit IMSI detacli initiation 

When an SGSN receives a Detach Request from an MS which is not in the Gs-NULL state, it shall check the detach 
type indicated. If the MS is indicating IMSI detach or combined IMSI and GPRS detach the SGSN shall send an 
BSSAP+-IMSI-DETACH-INDICATION message to the VLR indicating 'Explicit MS initiated IMSI detach from non- 
GPRS service' or 'Combined explicit MS initiated IMSI detach from GPRS and non-GPRS services'. 

After the sending of the BSSAP-n-IMSI-DETACH-INDICATION message to the VLR, the SGSN shall move the state 
of the association to Gs-NULL. The SGSN shall start timer T9 upon transmission of the BSSAP-n-IMSI-DETACH- 
INDICATION message and if timer T6-1 is running, timer T6-1 shall be stopped and reset.. 

9.2.2 Explicit IMSI detach Response 

If the SGSN receives a BSSAP-n-IMSI-DETACH-ACK message from the VLR, the SGSN shall stop timer T9. If the 
detach type received from the MS indicated IMSI only detach or combined IMSI and GPRS detach not due to switch 
off, the SGSN shall wait for the reception of the BSSAP-n-IMSI-DETACH-ACK message before sending the 
confirmation of the detach to the MS . 

9.2.3 Abnormal cases 

i) with switch off 

If the SGSN sent a BSSAP-n-IMSI-DETACH-INDICATION message for a combined IMSI and GPRS detach due to 
switch off and timer T9 expires, the SGSN shall repeat the BSS AP-n-IMSI-DETACH-INDICATION message a 
maximum of N9 times. 

ii) with no switch off 

If the SGSN sent a BSSAP-n-IMSI-DETACH-INDICATION message for a IMSI only detach or a combined IMSI and 
GPRS detach not due to switch off and timer T9 expires, the SGSN shall repeat the BSS AP-n-IMSI-DETACH- 
INDICATION message a maximum of N9 times. If no BSSAP-n-IMSI-DETACH-ACK is received after that the SGSN 
shall send the confirmation of the detach to the MS. 

9.3 Procedures in the VLR 

When a VLR receives an BSSAP-n-IMSI-DETACH-INDICATION message, the VLR shall send an BSSAP-n-IMSI- 
DETACH-ACK message to the sending SGSN. The state of the association for the MS shall be moved from any state to 
Gs-NULL. If the BSSAP-n-IMSI-DETACH-INDICATION message indicated 'Explicit MS initiated IMSI detach from 
non-GPRS service', the VLR marks the association as 'IMSI detached for non-GPRS services'. If the BSSAP-n-IMSI- 
DETACH-INDICATION message indicated 'Combined explicit MS initiated IMSI detach from GPRS and non-GPRS 
services', the VLR marks the association as 'IMSI detached for GPRS and non-GPRS services'. The VLR shall mark the 
MS as detached. 
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10 Implicit IIVISI detach from non-GPRS services 
procedure 

10.1 General description 

This procedure is used by the SGSN to indicate when an internal SGSN timer mechanism has caused the SGSN to 
delete the GMM context of an MS or mark its GMM context as detached. This procedure only applies to MSs that are 
not in the Gs-NULL state at the SGSN. 

The implicit IMSI detach from non-GPRS services procedure aborts any other ongoing procedure related to this MS on 
the Gs interface in the SGSN and in the VLR. 

The VLR and the MS should be synchronised as to whether the PBCCH or the BCCH is used, for any of the subsequent 
paging. In order to achieve this, the SGSN shall attempt to inform the VLR about the detach event by using a retry 
scheme if the initial delivery of the BSSAP+-IMSI-DETACH-INDICATION message fails. 

1 0.2 Procedures in the SGSN 

When the implicit IMSI detach from non-GPRS services procedure is started for an MS by the above mentioned 
internal SGSN timer mechanism, the SGSN shall send a BSSAP-n-IMSI-DETACH-INDICATION message to the VLR 
indicating 'Implicit SGSN initiated IMSI detach from GPRS and non-GPRS service'. 

After the sending of the BSSAP-n-IMSI-DETACH-INDICATION message, the SGSN shall move the state of the 
association to Gs-NULL. The SGSN shall start timer TIO upon transmission of the BSSAP-n-IMSI-DETACH- 
INDICATION message. 

If the SGSN receives a BSSAP-n-IMSI-DETACH-ACK message from the VLR, the SGSN shall stop timer TIO. 

If no BSSAP-H-IMSI-DETACH-ACK message is received by the SGSN to a previous BSSAP-n-IMSI-DETACH- 
INDICATION message before timer TIO expires, the SGSN shall repeat the BSSAP-n-IMSI-DETACH-INDICATION 
message a maximum of NIO times. The state of the association during the acknowledgement procedure remains Gs- 
NULL. 

1 0.3 Procedures in the VLR 

When a VLR receives the BSSAP-n-IMSI-DETACH-INDICATION message, the VLR shall send an BSSAP-n-IMSI- 
DETACH-ACK message to the sending SGSN. In addition, if the state of the Gs association is not Gs-NULL, the VLR 
proceeds as follows: 

- The VLR shall move the state of the association for the MS to Gs-NULL. If the VLR does not have an SCCP 
connection for the MS, the VLR shall mark the MS as detached. Additionally, the VLR marks the association as 
'IMSI implicitly detached for GPRS and non-GPRS services'. 



1 1 VLR failure procedure 
11.1 General description 

This procedure is used by the VLR to inform to the associated SGSNs about the recovery from an internal failure that 
has affected the association with the SGSNs. 

The VLR recovery procedure shall be handled in such a way that the signalling load on the VLR and SGSN does not 
create any overload problem. 
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1 1 .2 Procedures in the VLR 

11.2.1 VLR Reset Initiation 

In the event of a failure at the VLR which has resulted in the loss of SGSN association information on some MSs, the 
VLR shall move from any state to the Gs-NULL state for these MSs. The VLR shall also set the 'Confirmed by Radio 
Contact' restoration indicator to 'false' (see 3GPP TS 23.007) for affected MSs. The VLR shall not send any BSSAP+- 
MS-INFORMATION-REQUEST or BSSAP+-MM-INFORMATION-REQUEST messages to MSs with the SGSN 
association in the Gs-NULL state. 

When the VLR restarts a BSSAP+-RESET-INDICATION message shall be sent to all the SGSNs connected to the 
VLR by the Gs interface. This message indicates to the SGSN that for the MSs with an association to that VLR, the 
association is no longer reliable. The VLR shall also start timer TIL 

1 1 .2.2 VLR Reset Response 

Upon receipt of a BSSAP+-RESET-ACK message, the VLR shall stop the timer Til. 

1 1 .2.3 Abnormal cases 

If the VLR does not receive a BSSAP+-RESET-ACK message from that SGSN before the Tl 1 timer expires, the VLR 
shall retransmit the BSSAP+-RESET-INDICATION message. The retransmission is repeated a maximum of Nil times. 
If no BSSAP+-RESET-ACK is received after that a report shall be made to the O&M system. 

1 1 .3 Procedures in the SGSN 

Upon receipt of a BSSAP+-RESET-INDICATION message from the VLR, the SGSN is informed that all the 
associations with that VLR for all the MSs registered in the SGSN are no longer reliable because the VLR may have 
lost information about the state of the MSs and during the failure the VLR may have missed signalling messages. The 
SGSN shall set the 'VLR-Reliable' MM context variable to 'false'. The detach procedures for deleting the association are 
still applicable (clauses 8, 9 and 10). If the 'VLR-Reliable' MM context variable is set to 'false', upon reception of a 
Combined Routeing and Location Area update request or a periodic Routeing Area Update from the MS that is attached 
for non-GPRS service, the SGSN may request the re-attach to non-GPRS services, or may alternatively immediately 
perform the Location Update for non-GPRS services procedure towards the VLR. 

The SGSN sends a BSSAP-n-RESET-ACK message to the VLR. 



1 2 SGSN failure procedure 

12.1 General description 

This procedure is used by the SGSN to inform the associated VLRs about the recovery from an internal failure that has 
affected the association with the VLRs. 

The SGSN recovery procedure shall be handled in such a way that the signalling load on the VLR and SGSN does not 
create any overload problem. 

1 2.2 Procedures in the SGSN 
12.2.1 SGSN Reset Initiation 

In the event of a failure at the SGSN which has resulted in the loss of VLR association information on some MSs, the 
SGSN shall move from any state to the Gs-NULL state for these affected MSs. The SGSN shall also set the 'SGSN- 
Reset' MM context variable to 'true' and start the timer T12-1. When the timer T12-1 expires the 'SGSN-Reset' MM 
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context variable is set to 'false'. The value of the timer T12-1 shall be longer that the periodic routing area update timer 
at the SGSN. 

A BSSAP+-RESET-INDICATION message may be sent to all the VLRs connected to the SGSN by Gs interfaces. The 
BSSAP+-RESET-INDICATION message indicates to the VLR that all the associations with that particular SGSN for 
all the MSs registered in the VLR are no longer reliable. The normal procedures for updating the association are still 
applicable (clauses 6, 8, 9 and 10). The SGSN shall also start timer T12-2. 

If no BSSAP+-RESET-INDICATION is sent, the SGSN shall move from any state to the Gs-NULL state only the 
associations of the MSs affected by the loss of VLR association information. 

NOTE: The option to not send any BSSAP+-RESET-INDICATION message to all the VLRs connected to the 
SGSN by Gs interfaces reduces subsequent paging signalling initiated by VLRs by avoiding a complete 
search of the MS on the entire VLR area. 

12.2.2 SGSN Reset Response 

Upon receipt of a BSSAP+-RESET-ACK message, the SGSN shall stop the timer T12-2. 

12.2.3 Abnormal cases 

If the SGSN does not receive a BSSAP+-RESET-ACK message from that VLR before the T12-2 timer expires, the 
SGSN shall retransmit the BSSAP+-RESET-INDICATION message. The retransmission is repeated a maximum of 
N12 times. If no BSSAP+-RESET-ACK is received after a report shall be to made the O&M system. 

1 2.3 Procedures in the VLR 

Upon receipt of a BSSAP+-RESET-INDICATION message from the SGSN, the VLR is informed that all the 
associations with that SGSN for all the MSs registered in the SGSN are no longer reliable because the SGSN may have 
lost information about the state of the MSs for that VLR and during the failure the SGSN may have missed signalling 
messages. The VLR shall either: 

set the 'Confirmed by Radio Contact' restoration indicator to 'false' in all the associations containing the restarted 
SGSN and set the state of all the Gs associations containing the restarted SGSN to the Gs-NULL state; or 

keep the 'Confirmed by Radio Contact' restoration indication and the state of all the Gs associations containing 
the restarted SGSN unchanged. 

NOTE: The option to not set the 'Confirmed by Radio Contact' restoration indicator to 'false' in all the 

associations containing the restarted SGSN reduces subsequent paging signalling the VLR can initiate by 
avoiding a complete search of the MS on the entire VLR area. 

The VLR shall then send a BSSAP+-RESET-ACK message to the SGSN. 

If the 'Confirmed by Radio Contact' restoration indicator is 'false' the VLR may send paging messages on the Gs, A and 
lu-CS interfaces. 



13 HLR failure 

This clause decribes the SGSN behaviour towards the VLR as a consequence of an HLR reset. 



13.1 General description 



In the case of an HLR failure, the HLR informs the associated SGSNs about the recovery from an internal failure that 
has affected the association with the SGSNs according to the HLR reset procedure specified in 3GPP TS 29.002. 

This information is used in the SGSN to trigger the VLR to perform a location update towards the HLR in order to 
restore the HLR subscriber data. 
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1 3.2 Procedures in the SGSN 

Upon receipt of a HLR reset indication from the HLR, the SGSN shall set the NGAF for all registered MSs in the 
SGSN for which a valid MSC/VLR-association exists. 

Upon detection of any activity (either signalling or data) from the MS, the SGSN shall report to the VLR if the NGAF is 
set for this MS. If the SGSN detects GPRS signalling that leads to a procedure towards the VLR, the SGSN shall follow 
this procedure and reset the NGAF. If the SGSN detects activity that does not lead to any procedure towards the VLR, 
the SGSN shall send an BSSAP+-MS-ACTIVITY-INDICATION message towards the VLR and reset the NGAF. The 
activity indication may be delayed by the SGSN for a maximum operator-configuration depending time period to avoid 
high signalling load. 



14 MS Information procedure 

14.1 General description 

The MS Information procedure is used by the VLR to request specific parameters about the MS. If the target MS for an 
MS Information procedure or a Provide Subscriber Info procedure (see 3GPP TS 23.018 and 3GPP TS 29.002) is GPRS 
attached (i.e. the state of the association to Gs-ASSOCIATED) the VLR may decide to perform the procedure via 
GPRS. The outcome of the MS Information procedure does not change the state of the association at the VLR or SGSN. 

14.2 Procedures in the VLR 

If the target MS for the MS information procedure is GPRS attached and the state of the association for the MS Gs- 
ASSOCIATED, the VLR may initiate the MS information procedure by transferring a BSSAP-n-MS-INFORMATION- 
REQUEST message to the SGSN. If the state of the association is LA-UPDATE PRESENT, the VLR shall wait until 
this state is exited. The VLR starts the timer T14. The BSSAP-n-MS-INFORMATION-REQUEST message specifies 
the requested information parameters in the Information requested information element. 

Upon receipt of a BSSAP-n-MS-INFORMATION-RESPONSE the VLR shall stop timer T14. If no BSSAP-n-MS- 
INFORMATION-RESPONSE for that MS is received before the expiry of timer T14the VLR shall stop the Gs 
interface MS information procedure. The VLR may perform other actions to obtain the information about the MS (e.g. 
retry, or send a DTAP IDENTITY REQUEST message on the A interface). 

1 4.3 Procedures in the SGSN 

The SGSN shall examine the type of information that is requested and if it is stored in its database shall use this 
information in its response to the VLR. The BSSAP-n-MS-INFORMATION-RESPONSE message contains the 
information parameters as requested by the VLR. In A/Gb mode, the Mobile location information indicates a request for 
Cell Global Identity and Location information age. In lu mode, the Mobile location information indicates a request for 
Service Area Identification and Location information age. In this case, the SGSN shall use the Location Report Control 
procedure (see 3GPP TS 25.413) in order to retrieve the SA. 

If the SGSN receives an Information requested information element containing a 'not supported' value, then the value 
part of the Mobile station state information element in the BSSAP-n-MS-INFORMATION-RESPONSE message shall 
be set to 'Information requested not supported'. 

If the information is not locally available and it is a request for mobile identity information, the SGSN forwards the 
IDENTITY REQUEST message to the MS indicated in the message unless the GPRS activities of the MS are 
suspended. Upon receipt of the IDENTITY RESPONSE message from the MS, the SGSN shall send a BSSAP-n-MS- 
INFORMATION-RESPONSE message. The BSSAP-n-MS-INFORMATION-RESPONSE message contains the 
information parameters as requested by the VLR. If the GPRS activities of the MS are suspended the SGSN shall return 
a BSSAP-H-MS-INFORMATION-RESPONSE message indicating in the Mobile station state IE 'SUSPENDED'. If the 
requested information is not available or obtainable at the SGSN, the SGSN shall return a BSSAP-n-MS- 
INFORMATION-RESPONSE message to the VLR without the requested information. The SGSN should include the 
Mobile station state IE in all BSSAP-n-MS-INFORMATION-RESPONSE messages. 
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If the IMSI is not known at the SGSN, the SGSN shall return a BSSAP+-MS-INFORMATION-RESPONSE message 
indicating in the Mobile station state IE 'IMSI unknown'. 



15 MM information procedure 

15.1 General description 

The MM information procedure may be performed by the VLR via GPRS if the target MS for the MM information 
procedure is IMSI attached to both GPRS and non-GPRS services (i.e. the state of the association is Gs- 
ASSOCIATED). The outcome of the MM Information procedure does not change the state of the association at the 
VLR or SGSN. 

15.2 Procedures in the VLR 

If the target MS for the MM information procedure is GPRS attached class A or B MS, the state of the association is 
Gs- ASSOCIATED, the VLR may initiate the MM information procedure by transferring a BSSAP+-MM- 
INFORMATION-REQUEST message to the SGSN. 

1 5.3 Procedures in the SGSN 

If the state of the association at the SGSN is not Gs-NULL, and the network only spans one time zone, the SGSN shall 
keep the information elements in the MM information unchanged. 

NOTE: For the determination of the number of time zones, both CS and PS domain are taken into account. 

If the network spans more than one time zone, the SGSN shall check and update the contents of the MM information 
information element as follows: 

if Network Daylight Saving Time has been included in the MM information, then the SGSN shall discard the 
Network Daylight Saving Time; 

if Local Time Zone has been included in the MM information, then the SGSN shall replace the Local Time Zone 
with the Local Time Zone applicable for this MS. In addition, if the local time zone in the SGSN has been 
adjusted for daylight saving time, the SGSN shall indicate this by including the value used for adjustment in 
Network Daylight Saving Time IE in the MM information; 

if Universal time and local time zone has been included in the MM information, then the SGSN shall replace it 
with the Universal time and local time zone applicable for this MS. In addition, if the local time zone in the 
SGSN has been adjusted for daylight saving time, the SGSN shall indicate this by including the value used for 
adjustment in Network Daylight Saving Time IE in the MM information; and 

other information elements in the MM information are kept unchanged. 

The SGSN shall then send the resultant MM-INFORMATION message to the MS indicated. 



16 Error Handling and Future Compatibility 
16.1 General 

This clause specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data by the receiving 
entity. These procedures are called "error handling procedures", but in addition to providing recovery mechanisms for 
error situations they define a compatibility mechanism for future extensions of the protocol. 

In this clause the following terminology is used: 
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an IE is defined to be syntactically incorrect in a message if it contains at least one value defined as "reserved", 
or if its value part violates coding rules. However, it is not a syntactical error that an IE specifies in its Length 
Indicator a greater length than defined in the relevant clause; and 

a message is defined to have semantically incorrect contents if it contains information which, possibly dependant 
on the state of the receiver, is in contradiction to the resources of the receiver and/or to the procedural part of 
3GPPTS 29.018. 

When a receiving entity detects the need to send a BSSAP+-MOBILE-STATUS message (see errors detailed below), 
the entity shall copy the IMSI IE value (if included) of the incorrect message to the IMSI IE on the BSS AP+-MOBILE- 
STATUS message. The message in error is also included in the BSSAP+-MOBILE-STATUS message. Both the 
receiving and the sending entity shall abandon the procedure related to the incorrect message and return to the state 
from where the procedure related to the incorrect message was started. 

A BSSAP+-MOBILE-STATUS message shall not be sent in response to a received BSSAP+-MOBILE-STATUS 

message. 

Both the receiving and the sending entity shall inform the O&M entity upon sending or receiving a BSSAP+-MOBILE- 
STATUS message. 

The next clauses in this clause shall be applied in order of precedence. 

1 6.2 Message too short 

When a message is received that is too short to contain a complete message type information element, that message 
shall be ignored. 

1 6.3 Unknown or unforeseen message type 

If a message is received with a message type not defined or not implemented by the receiver it shall ignore the message. 
A BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "message unknown" and the Erroneous 
message IE containing the received message shall be returned. 

If a message is received that is not compatible with the protocol state, a BSSAP+-MOBILE-STATUS message with the 
Gs Cause Value set to "message not compatible with the protocol state" and the erroneous message shall be returned. 

If a message is received that is not defined to be received by that entity (i.e. the message is sent in the wrong direction) 
it shall be treated as unknown message and the message shall be ignored. A BSSAP+-MOBILE-STATUS message with 
the Gs Cause Value set to "message unknown" and the Erroneous message IE containing the received message shall be 
returned. 

16.4 Missing mandatory information element 

When on receipt of a message, and a "missing mandatory IE" error is diagnosed, the receiver shall ignore the message 
and return a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "missing mandatory information 
element" and shall return the Erroneous message information element containing the received message. 

16.5 lEs unknown or unforeseen in the message 

All lEs unknown or unforeseen in a message shall be ignored. 

1 6.6 Out of sequence lEs 

All lEs that are out of sequence shall be ignored. 
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16.7 Repeated I Es 

If an information element with format T, TV, or TLV is repeated in a message in which repetition of the information 
element is not specified, only the contents of the information element appearing first shall be handled and all subsequent 
repetitions of the information element shall be ignored. When repetition of information elements is specified, only the 
contents of specified repeated information elements shall be handled. If the limit on repetition of information elements 
is exceeded, the contents of information elements appearing first up to the limit of repetitions shall be handled and all 
subsequent repetitions of the information element shall be ignored. 

16.8 Syntactically incorrect mandatory IE. 

On receipt of a message which contains a syntactically incorrect mandatory IE, the receiver shall ignore the message 
and return a BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "invalid mandatory information" and 
shall return the Erroneous message information element containing the received message. 

16.9 Syntactically incorrect optional lEs 

All optional lEs that are syntactically incorrect in a message shall be treated as not present in the message. 

16.10 Conditional IE errors 

When a VLR or SGSN receives a message and diagnoses a "missing conditional IE" error or an "unexpected 
conditional IE" error or when it receives a message containing at least one syntactically incorrect conditional IE which 
is required to be present in the message, a VLR or SGSN shall ignore the message and return a BSSAP+-MOBILE- 
STATUS message with the Gs Cause Value set to "conditional IE error" and shall return the Erroneous message 
information element containing the received message. 

When a VLR or SGSN receives a message containing a syntactically incorrect conditional IE which is not required to 
be present in the message, nor required to be absent in the message, then a VLR or SGSN shall ignore that IE. 

1 6.1 1 lEs with semantically incorrect contents 

When an IE with semantically incorrect contents is received, the foreseen reactions of the procedural part of 
3GPP TS 29.018 are performed. 

If however no such reactions are specified, the receiving entity shall ignore that IE and treat the rest of the message. If, 
because this IE was ignored, the rest of the message can no longer be handled then the receiving entity shall return a 
BSSAP+-MOBILE-STATUS message with the Gs Cause Value set to "semantically incorrect message" and shall return 
the Erroneous message information element containing the received message. 



1 7 Message functional definitions and contents 

This clause defines the structure of the messages that are sent between the SGSN and the VLR. 

1 7. 1 Message Contents 

17.1.1 BSSAP+-ALERT-ACK message 

This message is sent by the SGSN to the VLR to acknowledge a previous BSSAP+-ALERT-REQUEST message. 
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Table 17.1.1/3GPP TS 29.018: BSSAP+-ALERT-ACK message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 



1 7.1 .2 BSSAP+-ALERT-REJECT message 

This message is sent from the SGSN to the VLR to indicate that the SGSN could not identify the IMSI indicated in the 
BSSAP+-ALERT-Request message. 

Table 17.1.2/3GPP TS 29.018: BSSAP+-ALERT-REJECT message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Gs Cause 


Gs Cause 
18.4.7 


M 


TLV 


3 



17.1.2.1 Gs Cause 

The value part which is typically sent for this information element in this message is 'IMSI unknown'. 

1 7.1 .3 BSSAP+-ALERT-REQUEST message 

This message is sent by the VLR to the SGSN to request an indication when next activity from the MS is detected. 
Table 17.1.3/3GPP TS 29.018: BSSAP+-ALERT-REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 



17.1.4 BSSAP+-DOWNLINK-TUNNEL-REQUEST message 

This message is sent from the non-GSM MSC/VLR to the SGSN to convey a tunneling payload to the MS identified by 
the specified IMSI. 

Table 17.1.4/3GPP TS 29.018: BSSAP+-DOWNLINK-TUNNEL-REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


VLR number 


VLR number 
18.4.26 


M 


TLV 


5-11 


Downlink Tunnel Payload Control and 
Info 


Downlink Tunnel Payload Control and 

Info 

18.4.3 


M 


TLV 


3-223 
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17.1 .5 BSSAP+-GPRS-DETACH-ACK message 

This message is sent by the VLR to the SGSN to acknowledge a previous BSSAP+-GPRS-DETACH-Indication 

message. 

Table 17.1.5/3GPP TS 29.018: BSSAP+-GPRS-DETACH-ACK message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 



17.1.6 BSSAP+-GPRS-DETACH-INDICATION message 

This message is sent by the SGSN to the VLR to indicate a GPRS detach performed from the MS or the SGSN. The 
type of detach is indicated in the IMSI detach from GPRS service type IE. 

Table 17.1.6/3GPP TS 29.018: BSSAP+-GPRS-DETACH-INDICATION message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


SGSN number 


SGSN number 
18.4.22 


M 


TLV 


5-11 


IMSI detach from GPRS service type 


IMSI detacli from GPRS service type 
18.4.11 


M 


TLV 


3 


Cell global identity 


Cell global identity 
18.4.1 





TLV 


10 


Service area identification 


Service area identification 
18.4.21b 





TLV 


9 



1 7.1 .6.1 Cell global identity (A/Gb mode only) 

In A/Gb mode, the SGSN shall include the Cell global identity where the mobile was in the last radio contact. 

1 7.1 .6.2 Service area identification (lu mode only) 

In lu mode, the SGSN should include the Service area identification where the mobile was in the last radio contact. 

17.1.7 BSSAP+-IMSI-DETACH-ACK message 

This message is sent by the VLR to the SGSN to acknowledge a previous BSSAP-n-IMSI-DETACH-Indication 
message. 

Table 17.1.7/3GPP TS 29.018: BSSAP+-IMSI-DETACH-ACK message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 
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17.1.8 BSSAP+-IMSI-DETACH-INDICATION message 

This message is sent by the SGSN to the VLR to indicate an IMSI detach performed from the MS. The type of detach is 
indicated in the IMSI detach from non-GPRS service type IE. 

Table 17.1.8/3GPP TS 29.018: BSSAP+-IMSI-DETACH-INDICATION message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


SGSN number 


SGSN number 
18.4.22 


M 


TLV 


5-11 


IMSI detach from non-GPRS service 
type 


IMSI detach from non-GPRS service 
type 18.4.12 


M 


TLV 


3 


Cell global identity 


Cell global identity 
18.4.1 





TLV 


10 


Location information age 


Location information age 
18.4.15 





TLV 


4 


Service area identification 


Service area identification 
18.4.21b 





TLV 


9 



1 7.1 .8.1 Cell global identity (A/Gb mode only) 

In A/Gb mode, the SGSN shall include the Cell global identity where the mobile was in the last radio contact. 

1 7.1 .8.2 Location information age 

If the detach is due to implicit detach and the Cell global identity is available, then the SGSN should include the 
Location information age. 

1 7.1 .8.3 Service area identification (lu mode only) 

In lu mode, the SGSN should include the Service area identification where the mobile was in the last radio contact. 

1 7.1 .9 BSSAP+-LOCATION-UPDATE-ACCEPT message 

This message is sent by the VLR to the SGSN to indicate that update or IMSI attach in the VLR has been completed. 
Table 17.1.9/3GPP TS 29.018: BSSAP+-LOCATION-UPDATE-ACCEPT message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Location area identifier 


Location area identifier 
18.4.14 


M 


TLV 


7 


NewTMSI,orlMSI 


Mobile identity 
18.4.17 





TLV 


6-10 



17.1.9.1 NewTMSI, orlMSI 

This information element represents the identity to be used for (and then by) the MS. 

If this information element is an IMSI, then the mobile station is not allocated any TMSI (and deletes any TMSI 
accordingly). If this information element is a TMSI, then the mobile station will use this TMSI as the new temporary 
identity (the MS deletes its old TMSI and stores the new TMSI). If neither a TMSI nor an IMSI are included in this 
information element, the old TMSI, if any available, will be kept. 
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17.1.10 BSSAP+-LOCATION-UPDATE-REJECT message 
17.1.10.1 Message definition 

This message is sent by the VLR to the SGSN to indicate that location update or IMSI attach has failed. 

Table 17.1.10/3GPP TS 29.018: BSSAP+-LOCATION-UPDATE-REJECT message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Reject cause 


Reject cause 
18.4.21 


M 


TLV 


3 


Location area identifier 


Location area identifier 
18.4.14 





TLV 


7 



17.1.10.2 Location area identifier 

The VLR shall include this information element. 



17.1.11 BSSAP+-LOCATION-UPDATE-REQUEST message 

This message is sent by the SGSN to the VLR either to request update of its location file (normal update) or to request 
IMSI attach. 

Table 17.1.11/3GPP TS 29.018: BSSAP+-LOCATION-UPDATE-REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


SGSN number 


SGSN number 
18.4.22 


M 


TLV 


5-11 


Update type 


GPRS location update type 
18.4.6 


M 


TLV 


3 


New Cell global identity 


Cell global identity 
18.4.1 


M 


TLV 


10 


Mobile station classmark 


Mobile station classmark 1 
18.4.18 


M 


TLV 


3 


Old location area identifier 


Location area identifier 
18.4.14 





TLV 


7 


TMSI status 


TMSI status 
18.4.24 





TLV 


3 


New service area identification 


Service area identification 
18.4.21b 





TLV 


9 


IMEISV 


IMEISV 
18.4.9 





TLV 


10 



1 7.1 .1 1 .1 Old location area identifier 

This information element should be included. 

17.1.11.2 New cell global identity 

In A/Gb mode, the cell global identity which shall be included is the one where the MS is in the current radio contact. 
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In lu mode, the cell global identity which shall be included indicates where the MS is in the current location area. The 
cell identity part of this information shall be ignored by the VLR. 

In a shared network, the PLMN identity contained in the cell global identity shall be the PLMN identity of the selected 
core network operator (see 3GPP TS 23.251 [24]). 

17.1.11.3 TMS I status 

This information element shall be included if the TMSI status received in the ATTACH REQUEST or ROUTING 
AREA UPDATING REQUEST message from the MS indicates, that no valid TMSI is available in the MS. 



17.1.11.4 



Mobile station classmark 



This information element does not serve any useful purpose, but shall be included for reasons of compatibility with 
earlier versions of the protocol. To ease interworking with old VLR equipment, the SGSN shall encode the contents of 
this information element as: revision level 'GSM phase 2', 'early classmark sending supported', 'encryption algorithm 
A5/1 supported', and RF power capability 'class 1 '. 

17.1.11.5 New service area identification 

In lu mode, the service area identification which should be included is the one where the MS is in the current radio 
contact. 

In a shared network, the PLMN identity contained in the service area identification shall be the PLMN identity of the 
selected core network operator (see 3GPP TS 23.251 [24]). 



17.1.11.6 



IMEISV 



This information element shall be included, if the SGSN supports the "Provision of UE Specific Behaviour Information 
to Network Entities" or the "Automatic Device Detection", or the 'Trace for Management Based 
Activation/Deactivation'. 

17.1.12 BSSAP+-MM-INFORMATION-REQUEST 

This message is sent by the VLR to the SGSN to provide the MS with subscriber specific information. 

Table 17.1.12/3GPP TS 29.018: BSSAP+-MM-INFORMATION-REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


MM information 


MM information 
18.4.16 





TLV 


3-n 



17.1.12.1 MM information 

This information element should be included in this message. 

17.1.13 BSSAP+-MOBILE-STATUS message 

This message is sent by both the SGSN or the VLR to indicate an error. 
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Table 17.1.13/3GPP TS 29.018: BSSAP+-MOBILE-STATUS message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 





TLV 


6-10 


Gs Cause 


Gs Cause 
18.4.7 


M 


TLV 


3 


Erroneous message 


Erroneous message 
18.4.5 


M 


TLV 


3-n 



17.1.13.1 IMSI 

If the MS is identified by the IMSI, then this information element shall be included. 

17.1.14 BSSAP+-MS-ACTIVITY-INDICATION message 

This message is sent by the SGSN to the VLR to indicate that activity from an MS has been detected. 

Table 17.1.14/3GPP TS 29.018: BSSAP+-MS-ACTIVITY-INDICATION message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Cell global identity 


Cell global identity 
18.4.1 





TLV 


10 


Service area identification 


Service area identification 
18.4.21b 





TLV 


9 



1 7.1 .1 4.1 Cell global identity (A/Gb mode only) 

In A/Gb mode, the SGSN shall include the cell global identity where the MS was in the last radio contact. 

17.1.14.2 Service area identification (lu mode only) 

In lu mode, the SGSN should include the Service area identification where the mobile was in the last radio contact. 

17.1.15 BSSAP+-MS-INFORMATION-REQUEST message 

This message is sent from the VLR to the SGSN to request information associated with the indicated IMSI. The type of 
information requested is specified in the Information requested IE. 

Table 17.1.15/3GPP TS 29.018: BSSAP+-MS-INFORMATION-REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Information requested 


Information requested 
18.4.13 


M 


TLV 


3 
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17.1.16 BSSAP+-MS-INFORMATION-RESPONSE message 

This message is sent from the SGSN to the VLR as a response to a previous BSSAP+-MS-INFORMATION- 
REQUEST message. (At least one of the requested identities shall be sent). 

Table 17.1.16/3GPP TS 29.018: BSSAP+-MS-INFORMATION-RESPONSE message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


TMSI 


TMSI 
18.4.23 





TLV 


6 


PTMSI 


PTMSI 
18.4.20 





TLV 


6 


IMEI 


IMEI 
18.4.8 





TLV 


10 


IMEISV 


IMEISV 
18.4.9 





TLV 


10 


Cell global identity 


Cell global identity 
18.4.1 





TLV 


10 


Location information age 


Location information age 
18.4.15 





TLV 


4 


Mobile station state 


Mobile station state 
18.4.19 





TLV 


3 


Service area identification 


Service area identification 
18.4.21b 





TLV 


9 



17.1.16.1 



IMEI 



This information element should be included if it was requested in the BSSAP+-MS-INFORMATION-REQUEST 
message and if this information is obtainable. 

17.1.16.2 IMIESV 

This information element should be included if it was requested in the BSSAP+-MS-INFORMATION-REQUEST 
message and if this information is obtainable. 

1 7.1 .1 6.3 Cell global identity (A/Gb mode only) 

In A/Gb mode, cell global identity where the MS was in the last radio contact. 

This information element should be included if it was requested in the BSSAP+-MS-INFORMATION-REQUEST 
message and if this information is obtainable. 

17.1.16.4 Location information age 

Time in minutes since the MS last established a radio transaction. 

This information element should be included if it was requested in the BSSAP+-MS-INFORMATION-REQUEST 
message and if this information is obtainable. 

17.1.16.5 Mobile station state 

This information element should be included in this message, irrespective of the information requested. 

17.1.16.6 TMSI 

This information element should be included if it was requested in the BSSAP+-MS-INFORMATION-REQUEST 
message and if this information is obtainable. 
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1 7.1 .1 6.7 Service area identification (lu mode only) 

In lu mode, service area identification where the MS was in the last radio contact. 

This information element should be included if it was requested in the BSSAP+-MS-INFORMATION-REQUEST 
message and if this information is obtainable. 

17.1.17 BSSAP+-MS-UNREACHABLE message 

This message is sent from the SGSN to the VLR to indicate that, for example, paging could not be performed because 
the MS is marked as unreachable at the SGSN. 

Table 17.1.17/3GPP TS 29.018: BSSAP+-MS-UNREACHABLE message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Gs Cause 


Gs Cause 
18.4.7 


M 


TLV 


3 



17.1.17.1 Gs Cause 

The value part which is typically sent for this information element in this message is 'MS unreachable'. 

17.1.18 BSSAP+-PAGING-REJECT message 

This message is sent from the SGSN to the VLR to indicate that the delivery of a previous BSSAP+-PAGING- 
REQUEST message has failed. 

Table 17.1.18/3GPP TS 29.018: BSSAP+-PAGING-REJECT message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Gs Cause 


Gs Cause 
18.4.7 


M 


TLV 


3 



17.1.19 BSSAP+-PAGING-REQUEST message 

This message is sent from the VLR to the SGSN and contains sufficient information to allow the paging message to be 
transmitted by the correct cells at the correct time. 
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Table 17.1.19/3GPP TS 29.018: BSSAP+-PAGING_REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


VLR number 


VLR number 
18.4.26 


M 


TLV 


5-11 


TMSI 


TMSI 
18.4.23 





TLV 


6 


Location area identifier 


Location area identifier 
18.4.14 





TLV 


7 


Channel needed 


Channel needed 
18.4.2 





TLV 


3 


eMLPP Priority 


eMLPP Priority 
18.4.4 





TLV 


3 


Global CN-ld 


Global CN-ld 
18.4.27 





TLV 


7 



17.1.19.1 



TMSI 



This element is omitted in the exceptional case where the IMSI is used instead of the TMSI as a paging address at the 
radio interface. 

17.1.19.2 Location area identifier 

If the location area identifier is not included, then the SGSN shall page the MS in all the cells served by the VLR and 
the SGSN, unless the SGSN has reliable information about the location of the MS. 

17.1.19.3 Channel needed 

If the Channel needed Information Element is not present, then the default value is assumed to be "any channel". 

17.1.19.4 eMLPP priority 

This information element may be included when the subscriber has a subscription for eMLPP. 

17.1.19.5 Global CN-ld 

If the network supports the Intra Domain Connection of RAN Nodes to multiple CN Nodes functionality, this 
information element shall be included when MSC/VLR initiates paging by IMSI, via the Gs interface. 

17.1.20 BSSAP+-RESET-ACK message 

This message is sent from the SGSN or the VLR to acknowledge a previous BSSAP-n-RESET-INDICATION message. 
This message indicates that all the associations to the VLR or the SGSN have been be marked as invalid. 

The sending entity (either SGSN or VLR) includes its identity in the BSSAP-n-RESET-ACK message. 
Table 17.1.20/3GPP TS 29.018: BSSAP+-RESET-ACK message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


SGSN number 


SGSN number 
18.4.22 


C 


TLV 


5-11 


VLR number 


VLR number 
18.4.26 


C 


TLV 


5-11 
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17.1.20.1 SGSN number 

If the SGSN is the sending entity, then it shall indicate its address by including its SGSN number Information Element. 
Otherwise (i.e. if the VLR is the sending entity), then the SGSN number Information Element shall not be included. 

17.1.20.2 VLR number 

If the VLR is the sending entity, then it shall indicate its address by including its VLR number Information Element. 
Otherwise (i.e. if the SGSN is the sending entity), then the VLR number Information Element shall not be included. 

17.1.21 BSSAP+-RESET-INDICATION message 

This message is sent from the VLR to the SGSN to indicate that a failure in the VLR has occurred and all the 
associations to the VLR shall be marked as invalid. 

This message is also sent from the SGSN to the VLR to indicate that a failure in the SGSN has occurred and all the 
associations to the SGSN shall be marked as invalid. 

The sending entity (either SGSN or VLR) includes its identity in the BSSAP+-RESET-INDICATION message. 
Table 17.1.21/3GPP TS 29.018: BSSAP+-RESET-INDICATION message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


SGSN number 


SGSN number 
18.4.22 





TLV 


5-11 


VLR number 


VLR number 
18.4.26 





TLV 


5-11 



17.1.21.1 SGSN number 

If the SGSN is the sending entity, then it shall indicate its address by including its SGSN number Information Element. 
Otherwise (i.e. if the VLR is the sending entity), then the SGSN number Information Element shall not be included. 

17.1.21.2 VLR number 

If the VLR is the sending entity, then it shall indicate its address by including its VLR number Information Element. 
Otherwise (i.e. if the SGSN is the sending entity), then the VLR number Information Element shall not be included. 

17.1.22 BSSAP+-TMSI-REALLOCATION-COMPLETE message 

This message is sent by the SGSN to the VLR to indicate that TMSI reallocation on the MS has been successfully 
completed. 

Table 17.1.22/3GPP TS 29.018: BSSAP+-TMSI-REALLOCATION-COMPLETE message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


Cell global identity 


Cell global identity 
18.4.1 





TLV 


10 


Service area identification 


Service area identification 
18.4.21b 





TLV 


9 
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1 7.1 .22.1 Cell global identity (A/Gb mode only) 

The SGSN shall include the cell global identity where the Mobile Station was in the last radio contact. 

1 7.1 .22.2 Service area identification (lu mode only) 

In lu mode, the SGSN should include the Service area identification where the mobile was in the last radio contact. 

17.1.23 BSSAP+-UPLINK-TUNNEL-REQUEST message 

This message is sent from the SGSN to the non-GSM MSC/VLR to convey the tunneling payload received from the MS 
identified by the specified IMSI. 

Table 17.1.23/3GPP TS 29.018: BSSAP+-UPLINK-TUNNEL-REQUEST message content 



Information Element 


Type/Reference 


Presence 


Format 


Length 


Message type 


Message type 
18.2 


M 


V 


1 


IMSI 


IMSI 
18.4.10 


M 


TLV 


6-10 


SGSN number 


SGSN number 
18.4.22 


M 


TLV 


5-11 


Uplink Tunnel Payload Control and 
Info 


Uplink Tunnel Payload Control and 

Info 

18.4.25 


M 


TLV 


3-223 
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1 8 Message format and information element coding 

This clause specifies the coding of the Information Elements used in by the BSSAP+ protocol. The spare bits in the 
coding of an IE shall be set to zero by the sender and shall be ignored by the receiver. 

All unassigned codes (whether omitted or explicitely Unassigned in the text) shall be treated as unknown (see 
clause 16). 



18.1 Overview 



18.2 IVI ess age type 

Message type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. 
Table 18.2/3GPP TS 29.018: Message type information element 



87654321 


Message type 


Reference 


00000000 


Unassigned: \rea\e6 as an unknown Message type. 


18 and 16 


00000001 


BSSAP+-PAGING-REQUEST 


17.1.19 


0000001 


BSSAP+-PAGING-REJECT 


17.1.18 


000000 1 1 
to 

000001 10 


Unassigned: \rea\e6 as an unknown Message type. 


18 and 16 


00000111 


BSSAP+-DOWNLINK-TUNNEL-REQUEST 


17.1.4 


00001000 


BSSAP+-UPLINK-TUNNEL-REQUEST 


17.1.23 


0000100 1 


BSSAP+-LOGATION-UPDATE-REQUEST 


17.1.11 


00001010 


BSSAP+-LOCATION-UPDATE-AGGEPT 


17.1.9 


0000101 1 


BSSAP+-LOCATION-UPDATE-REJEGT 


17.1.10 


00001100 


BSSAP+-TMSI-REALLOGATION-GOMPLETE 


17.1.22 


00001101 


BSSAP+-ALERT-REQUEST 


17.1.3 


00001110 


BSSAP+-ALERT-AGK 


17.1.1 


00001111 


BSSAP+-ALERT-REJEGT 


17.1.2 


00010000 


BSSAP+-MS-AGTIVITY-INDICATION 


17.1.14 


00010001 


BSSAP+-GPRS-DETACH-INDIGATION 


17.1.6 


00010010 


BSSAP+-GPRS-DETAGH-ACK 


17.1.5 


00010011 


BSSAP+-IMSI-DETACH-INDIGATION 


17.1.8 


00010100 


BSSAP+-IMSI-DETAGH-AGK 


17.1.7 


0001010 1 


BSSAP+-RESET-INDIGATION 


17.1.21 


00010110 


BSSAP+-RESET-AGK 


17.1.20 


00010111 


BSSAP+-MS-INFORMATION-REQUEST 


17.1.15 


00011000 


BSSAP+-MS-INFORMATION-RESPONSE 


17.1.16 


00011001 


Unassigned: \.rea\e6 as an unknown Message type. 


18 and 16 


00011010 


BSSAP+-MM-INFORMATION-REQUEST 


17.1.12 


0001110 1 


BSSAP+-MOBILE-STATUS 


17.1.13 


00011110 


Unassigned: \.rea\e6 as an unknown Message type. 


18 and 16 


00011111 


BSSAP+-MS-UNREAGHABLE 


17.1.17 



£75/ 



3GPP TS 29.018 version 10.5.0 Release 10 



44 



ETSI TS 129 018 VI 0.5.0 (2012-01) 



18.3 Information Element Identifiers 

The next list shows the coding of the Information Element Identifiers used in the present document. 
Table 18.3/3GPP TS 29.018: Information Element Identifier coding 



87654321 


Information element 


Reference 


00000001 


IMSI 


18.4.10 


00000010 


VLR number 


18.4.26 


0000001 1 


TMSI 


18.4.23 


00000100 


Location area identifier 


18.4.14 


00000101 


Channel Needed 


18.4.2 


00000110 


elVILPP Priority 


18.4.4 


00000111 


TMSI status 


18.4.24 


00001000 


Gs cause 


18.4.7 


0000100 1 


SGSN number 


18.4.22 


00001010 


GPRS location update type 


18.4.6 


000010 11 


Global CN-ld 


18.4.27 


00001100 


Unasslgned: \rea\ed as an unknown lEI. 


18 and 16 


00001101 


Mobile station classmark 1 


18.4.18 


00001110 


Mobile identity 


18.4.17 


00001111 


Reject cause 


18.4.21 


00010000 


IMSI detach from GPRS service type 


18.4.11 


0001000 1 


IMSI detach from non-GPRS service type 


18.4.12 


00010010 


Information requested 


18.4.13 


00010011 


PTMSI 


18.4.20 


00010100 


IMEI 


18.4.8 


00010101 


IMEISV 


18.4.9 


00010110 


L/nass/gned; treated as an unknown lEI. 


18 and 16 


00010111 


MM information 


18.4.16 


00011000 


Cell Global Identity 


18.4.1 


00011001 


Location information age 


18.4.15 


000110 10 


Mobile station state 


18.4.19 


000110 11 


Erroneous message 


18.4.5 


00011100 


Downlink Tunnel Payload Control and Info 


18.4.3 


0001 1101 


Uplink Tunnel Payload Control and Info 


18.4.25 


00011110 


Service Area Identification 


18.4.21b 


00011111 
to 

11111111 


Unassigned: \rea\ed as an unknown lEI. 


18 and 16 



18.3a Length indicator 

The length indicator of the information elements consists of one octet and contains the binary encoding of the number 
of octets of the value part in the information elements. 

18.4 Information elements 
18.4.1 Cell global identity 

This information element uniquely identifies one cell. 
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8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 

to 
Octet 10 


The rest of the information element is coded as the the value part 

of the cell global id IE defined in 3GPP TS 48.01 8 (not including 

3GPP TS 48.018 lEI and 3GPP TS 48.018 length indicator). 



Figure 18.4.1/3GPP TS 29.018: Cell global identity IE 

18.4.2 Channel needed 

The purpose of the Channel Needed information element is to indicate which type of channel is needed for the 
transaction linked to the paging procedure. 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


The rest of the information element is coded as the IE! part and the 
value part of the Channel Needed IE defined in 3GPP TS 44.01 8. 



Figure 18.4.2/3GPP TS 29.018: Channel needed IE 



18.4.3 Downlink Tunnel Payload Control and Info 

This information element is used to convey the payload of octets to be delivered to the identified mobile. 





8 


7 1 6 1 5 1 4 1 


3 


1 2 1 1 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


Spare 


TOIVI Protocol Discriminator | 


E 


1 Tunnel Priority 


Octet 4 

to 
Octet n 


Tunnel payload 



TOM Protocol Discriminator: Identifies the protocol using tunnelling of non-GSM signalling. For coding, see 

3GPP TS 44.064. 
E: Cipher Request. When set to 1 indicates that the SGSN shall cipher the payload, when 

set to indicates that the SGSN shall not cipher the payload. 
Tunnel Priority: Indicates the priority of the Tunnel Payload. For coding, see table 20.1 : Association 

between Tunnel Priority and LLC SAPs. 

Figure 18.4.3/3GPP TS 29.018: Downlink Tunnel Payload Control and Info IE 

18.4.4 eMLPP Priority 

This element indicates the eMLPP-Priority. 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


The rest of the information element is coded as the value part of 

the elVILPP-Priority IE defined in 3GPP TS 48.008 (not including 

3GPP TS 48.008 lEI and 3GPP TS 48.008 length indicator). 
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Figure 18.4.4/3GPP TS 29.018: eMLPP Priority IE 

18.4.5 Erroneous message 

The Erroneous message IE is a TLV IE that encapsulates the message in error. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 
Octet n 


Erroneous message including the message type. 


NOTE: If the size of the erroneous message including the message type 
exceeded 255 octets, only the first 255 octets are included. 



Figure 18.4.5/3GPP TS 29.018: Erroneous message IE 



1 8.4.6 GPRS location update type 



The purpose of the GPRS location update type information element is to indicate to the VLR whether an IMSI attach or 
a normal location update has been performed by the MS. 





8 7 6 5 4 3 2 


1 1 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


GPRS location update type value 



Figure 18.4.6/3GPP TS 29.018: GPRS location update type IE 
Table 18.4.6/3GPP TS 29.018: GPRS location update type IE value part 



GPRS location 


update type value (octet 3) 












Bits 














87654321 














00000000 


Shall not be sent in this version 


of the 


protocol. 


If received, 


shall be treated as 


■00000010'. 


00000001 


IMSI attach 












00000010 


Normal location update 












0000001 1 
To 

11111111 


Shall not be sent in this version 


of the 


protocol. 


If received, 


to shall be treated 


as 00000010'. 















18.4.7 Gs cause 

The purpose of the value part of the Gs Cause information element is to indicate an error to the receiving entity. This 
could be a protocol data error or to indicate to the VLR the reason why a paging procedure could not be performed. 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


Gs Cause value 



Figure 18.4.7/3GPP TS 29.018: Gs Cause IE 
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Table 18.4.7/3GPP TS 29.018: Gs Cause IE value part 



Gs Cause value 

Bits 
8765432 1 
00000000 
00000001 
00000010 
0000001 1 
00000100 
00000101 
000001 10 
000001 1 1 
00001000 
00001001 
00001010 
0000101 1 
00001 100 
00001 101 
00001 1 10 
00001 1 1 1 
00010000 

to 

11111111 



(octet 3) 



Normal, unspecified in this version of the protocol. 

IMSI detached for GPRS services 

IMSI detached for GPRS and non-GPRS services 

IMSI unknown 

IMSI detached for non-GPRS services 

IMSI implicitly detached for non-GPRS services 

MS unreachable 

Message not compatible with the protocol state 

Missing mandatory information element 

Invalid mandatory information 

Conditional IE error 

Semantically incorrect message 

Message unknown 

Address error 

TOM functionality not supported 

Ciphering request cannot be accommodated 

Normal, unspecified in this version of the protocol 



NOTE: Normal, unspecified has the same meaning than in 3GPP TS 24.008, informative Annex H (UMTS 

specific cause values for call control). It is used to report a normal event, and should not be interpreted as 
syntactically incorrect nor unknown if received. 

18.4.8 IMEI 

The IMEI is coded as a sequence of BCD digits, compressed two into each octet. The IMEI consists of 15 digits (see 
3GPP TS 23.003). 





8 1 7 1 6 


1 5 1 4 1 


3 1 2 


1 


octet 1 


lEI 


octet 2 


length indicator 


octet 3 


digit 2 


digit 1 


octet 4 


digit 4 


digits 


octet 5 


digits 


digits 


octet 6 


digits 


digit? 


octet 7 


digit 10 


digit 9 


octet 8 


digit 12 


digit 11 


octet 9 


digit 14 


digit 13 


octet 10 


1 1 1 1 1 


1 1 


1 


1 






Figure 18.4.8/3GPP TS 29.018: IMEI IE 



18.4.9 IMEISV 



The IMEISV is coded as a sequence of BCD digits, compressed two into each octet. The IMEISV consists of 16 digits 
(see 3GPP TS 23.003). 
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8 1 7 1 6 


1 5 1 4 1 


3 1 2 


1 


octet 1 


lEI 


octet 2 


length indicator 


octet 3 


digit 2 


digit 1 


octet 4 


digit 4 


digits 


octet 5 


digits 


digits 


octet 6 


digits 


digit? 


octet 7 


digit 10 


digit 9 


octet 8 


digit 12 


digit 11 


octet 9 


digit 14 


digit 13 


octet 10 


digit 16 


digit 15 



Figure 18.4.9/3GPP TS 29.018: IMEISV IE 



18.4.10 IMSI 



The IMSI is coded as a sequence of BCD digits, compressed two into each octet. This is a variable length element, and 
includes a length indicator. The IMSI is defined in 3GPP TS 23.003. It shall not exceed 15 digits (see 3GPP TS 23.003). 





8 1 7 1 6 


1 5 1 4 1 


3 1 2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


IMSI digit 1 


* parity 


1 


1 


Octet 4 


IMSI digit 3 


IMSI digit 2 


Octet 4+x 


IMSI digit i+1 


IMSI digit i 



Figure 18.4.10/3GPP TS 29.018: IIVISI IE 

Where x = (i-2)/2 and i is always even 

* The value of the parity bit (bit 4 in octect 3) indicates: 

Even number of IMSI digits; 

1 Odd number of IMSI digits; 

If the number of IMSI digits is even then bits 5 to 8 of the last octet shall be filled with an end mark coded as 

nil. 
18.4.1 1 IMSI detach from GPRS service type 

The purpose of the IMSI detach from GPRS service type information element is to indicate to the VLR the type of IMSI 
detach from GPRS service performed by the MS or the SGSN. 





8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


IMSI detach from GPRS service type value 



Figure 18.4.1 1/3GPP TS 29.018: IMSI detach from GPRS service type IE 
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Table 18.4.11/3GPP TS 29.018: IMSI detach from GPRS service type IE value part 



IMSI detach from GPRS service type value (octet 3) 

Bits 
87654321 

00000000 Interpreted as reserved in this version of the protocol 
1 Network initiated IMSI detach from GPRS service 
00000010 MS initiated IMSI detach from GPRS service 
1 1 GPRS services not allowed 
00000100 

to Interpreted as reserved in this version of the protocol 

11111111 



1 8.4.1 2 IMSI detach from non-GPRS service type 

The purpose of the IMSI detach from non-GPRS service type information element is to indicate to the VLR if the type 
of IMSI detach from non-GPRS service was explicitly performed by the MS or implicitly performed by the SGSN. 





8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


IIVISI detach from non-GPRS service type value 



Figure 1 8.4.1 2/3GPP TS 29.018: IIUISI detach from non-GPRS service type IE 
Table 1 8.4.1 2/3GPP TS 29.018: IIVISI detach from non-GPRS service type IE value part 



IMSI detach from non-GPRS service type value (octet 3) 

Bits 
8765432 1 

00000000 Interpreted as reserved in this version of the protocol 
1 Explicit MS initiated IMSI detach from non-GPRS service 
10 Combined expUcit MS initiated IMSI detach from GPRS and non-GPRS services 
1 1 Implicit SGSN initiated IMSI detach from GPRS and non-GPRS services 
00000100 

to Interpreted as reserved in this version of the protocol 

11111111 



18.4.13 Information requested 



The Information requested IE is a TLV IE that indicates to the SGSN the type of information requested by the VLR. 
The coding of the V field is as follows. 





8 


7 


1 6 1 5 1 4 1 3 1 2 


1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Information requested value 



Figure 1 8.4.1 3/3GPP TS 29.018: Information requested IE 
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Table 1 8.4.1 3/3GPP TS 29.018: Information requested IE value part 



Information requested value (octet 3) 

Bits 
87654321 

00000000 Interpreted as Not supported in this version of the protocol. 

1 PTMSI 

10 IMEI 

11 IMEISV 

10 PTMSI and IMEI 

10 1 PTMSI and IMEISV 

110 IMEI and IMEISV 

111 PTMSI, IMEI, and IMEISV 

10 Mobile location information 

10 1 TMSI 

00001010 Interpreted as Not supported in this version of the protocol. 

to 
11111111 



NOTE: The behaviour of the receiver in the case of a Not supported value is described in clause 14.3, Procedures 
in the SGSN. 

1 8.4. 1 4 Location area identifier 

This element uniquely identifies one Location Area. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 
Octer 7 


The rest of the information element is coded as the value part of 

the location area identifier IE defined in 3GPP TS 48.018 (not 

including 3GPP TS 48.018 lEI and 3GPP TS 48.018 length 

indicator). 



Figure 1 8.4.1 4/3GPP TS 29.018: Location area identifier IE 



18.4.15 Location information age 



The Location information age IE is a TLV IE that indicates the elapsed time in minutes since the last network contact of 
the mobile station. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 
Octet 4 


The rest of the IE is coded as the value part of the 
AgeOfLocationlnformation as specified in 3GPP TS 29.002. 



Figure 1 8.4.1 5/3GPP TS 29.018: Location information age IE 
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18.4.16 MM information 

The MM information IE is a TLV IE that encapsulates the user information that the SGSN forwards to the MS. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 
Octet n 


User information: Tliis field is composed of one or more of the 
information elements of the IVIM information message as defined in 

3GPP TS 24.008, excluding the Protocol discriminator, Skip 

indicator and Message type. This field includes the lEI and length 

indicatior of the other information elements. 



Figure 18.4.16/3GPP TS 29.018: MM information IE 

18.4.17 Mobile identity 

The purpose of the Mobile identity information element is to provide either: 
- The International Mobile Subscriber Identity (IMS I); 
The Temporary Mobile Subscriber Identity (TMSI); 
The International Mobile Equipment Identity (IMEI); or 
The International Mobile Equipment Identity together with the Software Version number (IMEISV). 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length Indicator 


Octet 3 
Octet n 


The rest of the information element is coded as the value part of 

the mobile identity IE defined in 3GPP TS 24.008 (not including 

3GPP TS 24.008 lEI and 3GPP TS 24.008 length indicator). 



Figure 1 8.4.1 7/3GPP TS 29.018: Mobile identity IE 



1 8.4.1 8 Mobile station classmark 1 

The purpose of the Mobile Station Classmark 1 information element is to provide the network with information 
concerning aspects of high priority of the mobile station equipment. 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


The rest of the information element is coded as the value part of 

the mobile station classmark 1 IE defined in 3GPP TS 24.008 (not 

including 3GPP TS 24.008 IE!) 



Figure 1 8.4.1 8/3GPP TS 29.018: Mobile station classmark 1 IE 
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18.4.19 Mobile station state 

The Mobile station state IE is a TLV IE that indicates to the VLR the GMM and GSM states of the MS in the SGSN. 
The coding of the V field is as follows. 





8 


7 


6 5 4 3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


IVIobile station state value 



Figure 1 8.4.1 9/3GPP TS 29.018: Mobile station state IE 
Table 1 8.4.1 9/3GPP TS 29.018: Mobile station state IE value part 



Mobile station state value (octet 3) 


Bits 




87654321 




00000000 


IDLE or PMM-DET ACHED 


00000001 


STANDBY or PMM-IDLE, PDP contexts active 


00000010 


STANDBY or PMM-IDLE, 1 or more PDP 




contexts active 


0000001 1 


SUSPENDED, PDP contexts active 


00000100 


SUSPENDED, 1 or more PDP contexts active 


00000101 


READY or PMM-CONNECTED, PDP contexts 




active 


000001 10 


READY or PMM-CONNECTED, 1 or more PDP 




contexts active 


000001 1 1 


IMSI unknown 


00001000 


Information requested not supported 


00001001 


Shall not be sent in this version of the protocol. 


to 


If received, shall be treated as '00001000'. 


11111111 





18.4.20 PTMSI 

The PTMSI consists of 4 octets. It can be coded using a full hexadecimal representation (see 3GPP TS 23.003). 





8|7|6|5|4|3| 


2 1 1 


octet 1 


lEI 


octet 2 


length indicator 


octet 3 


PTMSI octet 1 


octet 4 


PTMSI octet 2 


octet 5 


PTMSI octet 3 


octet 6 


PTMSI octet 4 



Figure 18.4.20/3GPP TS 29.018: PTMSI IE 
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18.4.21 Reject cause 



The purpose of the Reject Cause information element is to indicate the reason why a request from the mobile station is 
rejected by the network. 





8 7 6 5 4 3 2 1 


Octet 1 


lEI 


Octet 2 


Length Indicator 


Octet 3 


The rest of the information element is coded as the value part of 

the reject cause IE defined in 3GPP TS 24.008, not including 

3GPPTS 24.008 lEI. 



Figure 18.4.21/3GPP TS 29.018: Reject cause IE 



18.4.21b Service Area Identification 

This information element uniquely identifies one service area. 



Octet 1 
Octet 2 
Octet 3 

to 
Octet 9 



lEI 



Length indicator 



The rest of the information element is coded as the the value part 

of the SAI IE defined in 3GPP TS 25.413 (not including 

3GPP TS 25.413 lEI and 3GPP TS 25.413 length indicator). 



Figure 18.4.27/3GPP TS 29.018: Service Area Identification IE 

18.4.22 SGSN number 

The SGSN number is coded as a sequence of TBCD digits (as specified in 3GPP TS 29.002), compressed two into each 
octet. The Number is in international E.164 format as indicated by Octet 3 which coding is specified in 
3GPP TS 29.002. This is a variable length information element, and includes a length indicator. The value part of the 
SGSN number information element (not including lEI, Length indicator and Octet 3) shall not exceed 15 digits. 
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Octet 1 


lEI 
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Octet 3 
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1 


1 1 
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Figure 18.4.22/3GPP TS 29.018: SGSN number IE 
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18.4.23 TMSI 

The TMSI consists of 4 octets. It can be coded using a full hexadecimal representation (see 3GPP TS 23.003). 





8 7 6 5 4 3 


2 1 1 


octet 1 


lEI 


octet 2 


length indicator 


octet 3 


TMSI octet 1 


octet 4 


TMSI octet 2 


octet 5 


TMSI octet 3 


octet 6 


TMSI octet 4 



18.4.24 TMSI status 



Figure 18.4.23/3GPP TS 29.018: TMSI IE 



The purpose of the TMSI status information element is to indicate to the VLR whether a valid TMSI is available in the 
MS. 





8 
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1 5 1 4 1 


3 
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1 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Spare 


TMSI 
flag 



Figure 18.4.24/3GPP TS 29.018: TMSI status IE 
Table 18.4.24/3GPP TS 29.018: TMSI status IE value part 



TMSI flag (octet 3) 

Bit 

1 

no valid TMSI available 

1 valid TMSI available 

Bits 2-8 in octet 3 are spare and shall be coded all equal to 0. 
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18.4.25 Uplink Tunnel Payload Control and Info 

This information element is used to convey the payload of octets received from the mobile to the appropriate non-GSM 
MSC/VLR. 
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7 6 5 4 


3 


2 1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Spare 


TOM Protocol Discriminator 


E 


Tunnel Priority 


Octet 4 

to 
Octet n 


Tunnel payload 



TOIVI Protocol Discriminator: Identifies the protocol using tunnelling of non-GSIVI signalling. For coding, see 

3GPP TS 44.064. 
E: Cipher Request. When set to 1 indicates that the SGSN received the payload in 

ciphered form, when set to indicates that the SGSN did not receive the payload in 

ciphered form. 
Tunnel Priority: Indicates the priority of the Tunnel Payload. For coding, see Table 20.1 : Association 

between Tunnel Priority and LLC SAPs. 

Figure 18.4.25/3GPP TS 29.01 8:Upnlink Tunnel Payload Control and Info IE 

18.4.26 VLR number 

The VLR number is coded as a sequence of TBCD digits (as specified in 3GPP TS 29.002), compressed two into each 
octet. The Number is in international E.164 format as indicated by Octet 3 which coding is specified in 
3GPP TS 29.002. This is a variable length information element, and includes a length indicator. The value part of the 
VLR number information element (not including lEI, length indicator and Octet 3), shall not exceed 15 digits. 

Table 18.4.26/3GPP TS 29.018: VLR number IE 
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Octet 1 
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1 1 
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1 


1 
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18.4.27 Global CN-ld 

The Global CN-Id consists of a PLMN-Id and a CN-Id, see 3GPP TS 23.003. The PLMN-Id consists of MCC and MNC 
coded according to Location Area Identification in 3GPP TS 24.008. The CN-Id is an integer defined by O&M. The 
least significant bit of the CN-Id field is bit 1 of octet 7 and the most significant bit is bit 8 of octet 6. If the CN-Id does 
not fill the field reserved for it, the rest of the bits are set to '0'. 
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Table 18.4.27/3GPP TS 29.018: Global CN-ld IE 
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Length indicator 


Octet 3 


PLMN-Id 

Coded as octets 2 to 4 of the Location Area Identification IE, 

defined in 3GPP TS 24.008 (not including 3GPP TS 24.008 lEI 

and LAC). 


Octet 4 


Octet 5 


Octet 6 


r'M T^ (-TMXCnCD f\ /lf\Q<^ 


Octet 7 
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1 9 List of system variables 
19.1 Timers 

This clause lists the management timers specified for the operation of the BSSAP+ protocol. All the implementation 
shall support the range of values specified below. The specific value of the timers shall be under the control of the 
operator. 

Table 19.1/3GPP TS 29.018: Management Timers 



Timer 
name 


Default 
value 


Timer 
range 


Granularity 


Notes 


Relation to other timers 


T5 




2 s to 20 s 


100 ms 


Guards the Paging 
procedure at the VLB. 


Value is correlated to DRX parameter 
Split PG CYCLE (max possible = 16 s) 
Default should be set ace. to max split 
cycle supported by the SGSN (operator 
choice) 


16- 1 




10 s to 90s 


1 s 


Guards the Location Update 
procedure. 


It should be higher than 2 times the 
maximum transmission time in the Gs 
interface, plus the supervision timer of 
the Update Location procedure 
[3GPP TS 29.002] 


T6-2 


40 s 


5 s to 60 s 


1 s 


Guards the TIVISI 
reallocation procedure. 


It should be higher than 2 times the 
maximum transmission time in the Gs 
interface, plus 4 times T3350 
[3GPP TS 24.008] 


T7 


4s 


1 s to 30 s 


1 s 


Guards the Non-GPRS alert 
procedure. 


None. 


T8 


4s 


1s to 30 s 


1 s 


Guards the Explicit IMS! 
detach from GPRS services 
procedure. 


None. 


T9 


4s 


1-30 s 


1 s 


Guards the Explicit IIVISI 
detach from non-GPRS 
services procedure. 


None. 


no 


4s 


1-30 s 


1 s 


Guards the Implicit IIVISI 
detach from non-GPRS 
services procedure. 


None. 


T11 


4s 


1-120S 


1 s 


Guards the VLR reset 
procedure. 


None. 


T12-1 




8- 

60x384-h8 s 


1 min 


Controls the resetting of the 
'SGSN-Reset' variable. 


It should be longer than the longest 
Periodic RAU timer running on the 
SGSN, plus the transmission delay on 
the radio interface. 


T12-2 


4s 


1-120S 


1 sec 


Guards the SGSN reset 
procedure. 


None. 


T14 


- 


4-36 s 


1 s 


Guards the MS Information 
procedure. 


None 


NOTE: The Default value is the recommended value. 
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19.2 Retry counters 



This clause lists the management retry counters specified for the operation of the BSSAP+ protocol. The values 
indicated are recommended values. 

Table 19.2/3GPP TS 29.018: Management Retry counters 



Retry mnemonic 


Retry value 


Notes 


N7 


2 


Recommended value 


N8 


2 


Recommended value 


N9 


2 


Recommended value 


N10 


2 


Recommended value 


N11 


2 


Recommended value 


N12 


2 


Recommended value 



20 Procedures for Tunnelling Non-GSM Signalling 

This procedure is used to tunnel non-GSM signalling messages between an MS and a non-GSM MSC/VLR. 

20.1 Procedures in the non-GSM MSC/VLR 

When the non-GSM MSC/VLR has a message to be tunnelled to an MS, whose Gs state is not Gs-NULL, it shall send a 
BSSAP+-DOWNLINK-TUNNEL-REQUEST message to the SGSN associated with the MS. If LLC ciphering is 
required, the cipher request field E shall be set to 1 . The Tunnel Priority field for the payload shall be set as required. 
On receiving a BSSAP+-UPLINK-TUNNEL-REQUEST message from an SGSN, the action taken by the non-GSM 
MSC/VLR is technology dependent. 

20.2 Procedures in the SGSN 

A message received by the SGSN from an MS or sent by the SGSN to an MS on one of the Tunneling of Messages 
(TOM) LLC SAPs is called a TOM Protocol Envelope (see 3GPP TS 44.064). The TOM Protocol Envelope is 
composed of the TOM Protocol Header immediately followed by a Message Capsule. 

Upon receipt of a TOM Protocol Envelope with a TOM Protocol Header indicating the presence of one or more non- 
GSM signalling messages, the SGSN shall determine the non-GSM MSC/VLR to which the Message Capsule in the 
TOM Protocol Envelope shall be forwarded. The SGSN shall make this determination based upon the RAI of the MS, 
the TOM Protocol Discriminator field in the TOM Protocol Header, and TOM Protocol Discriminator specific 
information in the remaining octets (if any) in the TOM Protocol Header. The SGSN shall then forward a BSSAP-n- 
UPLINK-TUNNEL-REQUEST message to the selected non-GSM MSC/VLR with the received Message Capsule in 
the Tunnel Payload field. The Protocol Discriminator field in the BSSAP-H-UPLINK-TUNNEL-REQUEST message 
shall be set based on the TOM Protocol Discriminator in the TOM Protocol Envelope. Tunnel Priority field in the 
BSSAP-H-UPLINK-TUNNEL-REQUEST message shall be set based on the LLC SAP on which the TOM Protocol 
Envelope was received. The E field shall be set to 1 if the TOM Protocol Envelope was received by the LLC in ciphered 
form, otherwise it shall be set to 0. 
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Upon receipt of a BSSAP+-DOWNLINK-TUNNEL-REQUEST message from a non-GSM MSCA^LR, the SGSN shall 
construct a TOM Protocol Envelope by mapping the Tunnel Payload field to the Message Capsule portion of the TOM 
Protocol Envelope. The TOM Protocol Header shall be constructed based on the Protocol Discriminator in the 
BSSAP+-DOWNLINK-TUNNEL-REQUEST message. The SGSN shall then send the TOM Protocol Envelope to the 
MS on a specific LLC SAP. That LLC SAP shall be determined by the Tunnel Priority field in the BSSAP+- 
DOWNLINK-TUNNEL-REQUEST message. LLC ciphering shall be enabled or disabled based upon the value of the E 
field in this message. If the SGSN is unable to send the TOM Protocol Envelope to the indicated MS for any reason, 
including the inability to accommodate the ciphering request as indicated in the BSSAP+-DOWNLINK-TUNNEL- 
REQUEST message, then it shall send a BSSAP+-MOBILE-STATUS message to the non-GSM MSC/VLR with an 
appropriate Gs Cause code. 

The association between the LLC SAPs and the Tunnel Priority shall be as in the following table, where 00 is top-most 
priority and 1 1 is lowest priority. 

Table 20.1 : Association between Tunnel Priority and LLC SAPs 



Tunnel Priority 


LLC SAP 


00 


T0M2 


01 


Not defined 


10 


TOMS 


11 


Not defined 
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